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

Usuário:Gondim

2026-04-28T21:42:19Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim perfil2026.png|alt=|esquerda|miniaturadaimagem|252x252px]]
'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Fórum BCOP Fortaleza''' com a palestra: "'''Recomendações de segurança para provedores"''' com apresentação [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2487/Marcelo_Gondim_Recomendacoes_seguranca_provedores.pdf aqui] e vídeo [https://youtu.be/Qjgb7P3cG8k?t=9237 aqui]'''.''' Os arquivos anexos de configuração: [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2489/Marcelo_Gondim_filtros_edge_huawei.pdf filtros_edge_huawei], [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2490/spoofer.pdf spoofer] e [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2491/filtros_bng_huawei.pdf filtros_bng_huawei].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Moeda IX Fórum Fortaleza 2026:'''
[[Arquivo:Frum-bcop-fortaleza-2026 55178462504 o.jpg|esquerda|miniaturadaimagem]]
[[Arquivo:Frum-bcop-fortaleza-2026 55178206816 o.jpg|nenhum|miniaturadaimagem]]

 
'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Usuário:Gondim

2026-04-28T21:41:59Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim perfil2026.png|alt=|esquerda|miniaturadaimagem|263x263px]]
'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Fórum BCOP Fortaleza''' com a palestra: "'''Recomendações de segurança para provedores"''' com apresentação [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2487/Marcelo_Gondim_Recomendacoes_seguranca_provedores.pdf aqui] e vídeo [https://youtu.be/Qjgb7P3cG8k?t=9237 aqui]'''.''' Os arquivos anexos de configuração: [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2489/Marcelo_Gondim_filtros_edge_huawei.pdf filtros_edge_huawei], [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2490/spoofer.pdf spoofer] e [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2491/filtros_bng_huawei.pdf filtros_bng_huawei].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Moeda IX Fórum Fortaleza 2026:'''
[[Arquivo:Frum-bcop-fortaleza-2026 55178462504 o.jpg|esquerda|miniaturadaimagem]]
[[Arquivo:Frum-bcop-fortaleza-2026 55178206816 o.jpg|nenhum|miniaturadaimagem]]

 
'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Usuário:Gondim

2026-04-28T21:41:34Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim perfil2026.png|alt=|esquerda|miniaturadaimagem|275x275px]]
'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Fórum BCOP Fortaleza''' com a palestra: "'''Recomendações de segurança para provedores"''' com apresentação [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2487/Marcelo_Gondim_Recomendacoes_seguranca_provedores.pdf aqui] e vídeo [https://youtu.be/Qjgb7P3cG8k?t=9237 aqui]'''.''' Os arquivos anexos de configuração: [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2489/Marcelo_Gondim_filtros_edge_huawei.pdf filtros_edge_huawei], [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2490/spoofer.pdf spoofer] e [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2491/filtros_bng_huawei.pdf filtros_bng_huawei].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Moeda IX Fórum Fortaleza 2026:'''
[[Arquivo:Frum-bcop-fortaleza-2026 55178462504 o.jpg|esquerda|miniaturadaimagem]]
[[Arquivo:Frum-bcop-fortaleza-2026 55178206816 o.jpg|nenhum|miniaturadaimagem]]

 
'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Arquivo:Gondim perfil2026.png

2026-04-28T21:41:04Z

Gondim:

Gondim_perfil2026

Debian Cluster CEPH

2026-04-25T16:31:46Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama ceph.png|nenhum|miniaturadaimagem|483x483px]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|722x722px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|894x894px]]
Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Proxmox osd.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Proxmox osd2.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]

Debian Cluster CEPH

2026-04-25T16:29:45Z

Gondim:

Debian Cluster CEPH

2026-04-25T16:11:30Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama ceph.png|nenhum|miniaturadaimagem|483x483px]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|722x722px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|894x894px]]
Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Proxmox osd.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Proxmox osd2.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Arquivo:Proxmox osd2.png

2026-04-25T16:10:55Z

Gondim:

proxmox_osd2

Arquivo:Proxmox osd.png

2026-04-25T16:09:00Z

Gondim:

proxmox_osd

Debian Cluster CEPH

2026-04-25T16:08:05Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama ceph.png|nenhum|miniaturadaimagem|483x483px]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|722x722px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|894x894px]]
Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Osd img.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Resultado ceph.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Arquivo:Mon ceph.png

2026-04-25T16:05:35Z

Gondim:

mon_ceph

Arquivo:Nodeq ceph.png

2026-04-25T16:02:35Z

Gondim:

nodeq_ceph

Debian Cluster CEPH

2026-04-25T16:00:15Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama ceph.png|nenhum|miniaturadaimagem|483x483px]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''

Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|806x806px]]Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Osd img.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Resultado ceph.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Arquivo:Monmap.png

2026-04-25T15:58:47Z

Gondim:

Monmap

Arquivo:Qdevice.png

2026-04-25T15:55:09Z

Gondim:

qdevice

Debian Cluster CEPH

2026-04-25T15:54:03Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama ceph.png|nenhum|miniaturadaimagem|483x483px]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|677x677px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|806x806px]]Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Osd img.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Resultado ceph.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Debian Cluster CEPH

2026-04-25T15:50:31Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama cluster ceph.png|nenhum|alt=|commoldura|[[Arquivo:Diagrama ceph.png|nenhum|alt=|commoldura]]]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|677x677px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|806x806px]]Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Osd img.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Resultado ceph.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Debian Cluster CEPH

2026-04-25T15:49:41Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama cluster ceph.png|nenhum|alt=|commoldura|[[Arquivo:Diagrama ceph.png|nenhum|miniaturadaimagem|500x500px]]]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|677x677px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|806x806px]]Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Osd img.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Resultado ceph.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Debian Cluster CEPH

2026-04-25T15:49:17Z

Gondim:

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama cluster ceph.png|nenhum|alt=|commoldura|[[Arquivo:Diagrama ceph.png|nenhum|miniaturadaimagem]]]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|677x677px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|806x806px]]Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Osd img.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Resultado ceph.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Arquivo:Diagrama ceph.png

2026-04-25T15:48:24Z

Gondim:

diagrama_ceph

Debian Cluster CEPH

2026-04-25T15:47:19Z

Gondim: Criou página com '== Introdução == Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser c...'

== Introdução ==
Este artigo tem como foco explicar como adicionar um Debian GNU/Linux em um Proxmox Cluster + HA com 2 nodes. Como muitos sabem, um '''Cluster''' deve ser composto de no '''mínimo 3 nodes''' para que possa dar segurança, existir '''quorum''' e quando usamos '''CEPH''' também precisamos de pelo menos 3 nodes com '''OSDs''' para termos uma estabilidade e segurança no sistema. O problema é quando se quer fazer isso com apenas 2 servidores Proxmox. Comprar um terceiro servidor às vezes ainda não está nos planos mas você tem uma máquina parada, onde você pode adicionar 2 SSDs e com 4G de ram você pode adicionar ela no '''Cluster''' para servir de quorum e de disco '''CEPH'''. Dessa maneira você consegue com 2 servidores '''Proxmox''' e uma máquina que chamei de '''Quorum Device''', colocar em produção um Cluster com HA funcional.

== Diagrama ==
O diagrama abaixo será o ambiente de exemplo mas não falaremos de como construir um Cluster + HA com Proxmox. Nesse caso você precisará ter os 2 servidores já instalados e configurados em '''Cluster''' com '''CEPH'''. Aqui vamos apenas mostrar como adicionar um Debian GNU/Linux nesse Cluster e no CEPH.
[[Arquivo:Diagrama cluster ceph.png|nenhum|miniaturadaimagem|522x522px]]

== Pré-requisitos ==

* Debian GNU/Linux 13 (Trixie).
* Uma máquina com 4G ou 8G de ram.
* 1 SSD para instalar o sistema.
* 1 SSD para servir de '''OSD''' no '''CEPH'''.
*3 interfaces de rede. Uma para o acesso, outra para o '''Cluster''' e outra para o '''CEPH'''.

== Configurando o Qdevice no Debian ==
Uma vez instalado o Debian, precisamos configurar as 3 interfaces para a comunicação com seu Cluster Proxmox. Por exemplo:

* ens18 - IP 10.254.254.27/24 GW 10.254.254.1 (essa seria a interface com acesso à Internet para instalar os programas).
* ens19 - IP 192.168.1.3/24 (interface que deve se comunicar com a rede do Cluster, com os IPs dos nodes 192.168.1.1 e 192.168.1.2.
* ens20 - IP 192.168.2.3/24 (interface que se comunica com a rede CEPH, com os IPs 192.168.2.1 e 192.168.2.2.

Precisamos configurar o serviço SSHD para permitir conexão com root, pois o Proxmox vai precisar acessar o Debian. Para isso altere o arquivo '''/etc/ssh/sshd_config''' o parâmetro abaixo:
PermitRootLogin yes
Reinicie o serviço:
# systemctl restart sshd
No Debian vamos instalar o pacote '''corosync-qnetd''':
# apt install corosync-qnetd
Nos dois servidores Proxmox, no nosso exemplo PVE01 e PVE02 instalaremos o pacote '''corosync-qdevice''':
# apt install corosync-qdevice
Agora vá para o shell do seu '''Proxmox principal''', no meu caso o '''PVE01''' e adicione o Debian ao Cluster com o seguinte comando:
# pvecm qdevice setup 192.168.1.3
Com o comando '''pvecm status''' podemos ver como está o quorum e se tudo ocorreu bem, verá que agora temos 3 votos no lugar de 2 e um '''Qdevice''' no membership:
[[Arquivo:Qdevice.png|nenhum|miniaturadaimagem|748x748px]]
Agora em se tratando de Cluster, você tem o mínimo de votantes para o bom funcionamento e usando uma máquina simples com Debian.

== Adicionando um CEPH monitor e OSD ==
Agora precisamos tornar nosso '''CEPH''' saudável também e para isso vamos instalar os pacotes do CEPH do Proxmox no Debian. O CEPH precisa ser da mesma versão usada no Cluster Proxmox. Para os meus testes utilizei um '''Cluster Proxmox 9''' no '''PVE01''' e '''PVE02''' que utiliza o '''CEPH Squid 19.2'''. Então vamos adicionar o repositório:
# echo "deb <nowiki>http://download.proxmox.com/debian/ceph-squid</nowiki> trixie no-subscription" > /etc/apt/sources.list.d/ceph.list
# wget <nowiki>https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg</nowiki> -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg
Instalando os pacotes do CEPH:
# apt update
# apt install ceph ceph-common
Antes de prosseguir adicione no '''/etc/hosts''' do Debian:
192.168.2.1 node1
192.168.2.2 node2
192.168.2.3 nodeq
Estou chamando nosso '''Quorum Device''' com o hostname '''nodeq'''.

Agora precisaremos executar algumas tarefas no nosso '''PVE01''':
# ceph mon getmap -o /tmp/monmap

# monmaptool \
--add nodeq 192.168.2.3:6789 \
/tmp/monmap
Vamos checar se adicionamos o '''nodeq''' ao '''monmap''' com o comando: '''monmaptool --print /tmp/monmap'''
[[Arquivo:Monmap.png|nenhum|miniaturadaimagem|677x677px]]
Vamos gerar o '''keyring''' para usarmos no Debian:
# ceph auth get mon. -o /tmp/ceph.mon.keyring
Agora precisamos copiar todos os arquivos necessários do '''PVE01''' para o nosso Debian:
# scp /tmp/monmap root@192.168.2.3:/etc/ceph/
# scp /tmp/ceph.mon.keyring root@192.168.2.3:/etc/ceph/
# scp /etc/pve/ceph.conf root@192.168.2.3:/etc/ceph/
# scp /etc/pve/priv/ceph.client.admin.keyring root@192.168.2.3:/etc/ceph/

# scp /var/lib/ceph/bootstrap-osd/ceph.keyring \
root@192.168.2.3:/var/lib/ceph/bootstrap-osd/
'''Atenção''' '''agora''' pois vamos no nosso Debian alterar o arquivo '''/etc/ceph/ceph.conf'''. Primeiro modifique o parâmetro abaixo para incluir o IP '''192.168.2.3''':
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
Modifique os dois parâmetros abaixo e deixe eles iguais a estes:<pre>
[client]
keyring = /etc/ceph/$cluster.$name.keyring

[client.crash]
keyring = /etc/ceph/$cluster.$name.keyring
</pre>Adicione no final deste mesmo arquivo a configuração abaixo:<pre>
[mon.nodeq]
public_addr = 192.168.2.3
</pre>Ainda no '''Debian''' execute os comandos abaixo para prepararmos o ambiente pro '''CEPH''':
# mkdir -p /var/lib/ceph/mon/ceph-nodeq
# chown ceph:ceph /var/lib/ceph/mon/ceph-nodeq
# chmod 750 /var/lib/ceph/mon/ceph-nodeq
Vamos criar o monitor:
# ceph-mon --mkfs \
-i nodeq \
--monmap /etc/ceph/monmap \
--keyring /etc/ceph/ceph.mon.keyring

# chown -R ceph: /var/lib/ceph/mon/ceph-nodeq
# chown -R ceph: /etc/ceph/
# chmod 640 /etc/ceph/ceph.mon.keyring
# chmod 640 /etc/ceph/monmap
Este é o momento crucial para que tenhamos mais um monitor no nosso CEPH do Proxmox:
# systemctl enable ceph-mon@nodeq
# systemctl start ceph-mon@nodeq
Precisamos checar se o serviço subiu com o comando: '''systemctl status ceph-mon@nodeq'''

Se aparecer algo assim então parabéns, até aqui foi tudo OK:
[[Arquivo:Nodeq ceph.png|nenhum|miniaturadaimagem|806x806px]]Volte no Proxmox PVE01 e altere o '''/etc/pve/ceph.conf''' modificando para:
mon_host = 192.168.2.1 192.168.2.2 192.168.2.3
E adicionando no final do arquivo:
[mon.nodeq]
public_addr = 192.168.2.3
Agora ativamos, ainda no '''Proxmox PVE01''', o '''msgr2''':
# ceph mon enable-msgr2
No Debian reinicie o serviço:
# systemctl restart ceph-mon@nodeq
No '''Proxmox''' em '''CEPH''' verá um novo Monitor adicionado:
[[Arquivo:Mon ceph.png|nenhum|miniaturadaimagem|598x598px]]

== Adicionando o OSD no Debian ==
Agora vamos aos procedimentos para usarmos aquele SSD como OSD no CEPH. Vamos supor que o '''SSD livre''' seja o '''/dev/sdb''':
# apt install gdisk util-linux

# wipefs -a /dev/sdb
# sgdisk --zap-all /dev/sdb

Feito isso só precisamos criar o volume CEPH com o comando:
# ceph-volume lvm create --data /dev/sdb
Se tudo foi bem, nesse momento verá o '''OSD''' no seu '''Cluster Proxmox''':
[[Arquivo:Osd img.png|nenhum|miniaturadaimagem|1234x1234px]]
Olhando a saúde do nosso Cluster veremos:
[[Arquivo:Resultado ceph.png|nenhum|miniaturadaimagem|1235x1235px]]

== Conclusão ==
Aqui vemos em funcionamento um '''Cluster Proxmox + HA''' com 2 nós apenas e uma máquina Debian servindo como apoio no funcionamento e segurança do Cluster.

Gostou do artigo? Compartilhe!

Autor: [[Sobre mim|Marcelo Gondim]]
[[Categoria:Artigos Técnicos]]

Usuário:Gondim

2026-04-01T20:15:39Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Fórum BCOP Fortaleza''' com a palestra: "'''Recomendações de segurança para provedores"''' com apresentação [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2487/Marcelo_Gondim_Recomendacoes_seguranca_provedores.pdf aqui] e vídeo [https://youtu.be/Qjgb7P3cG8k?t=9237 aqui]'''.''' Os arquivos anexos de configuração: [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2489/Marcelo_Gondim_filtros_edge_huawei.pdf filtros_edge_huawei], [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2490/spoofer.pdf spoofer] e [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2491/filtros_bng_huawei.pdf filtros_bng_huawei].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Moeda IX Fórum Fortaleza 2026:'''
[[Arquivo:Frum-bcop-fortaleza-2026 55178462504 o.jpg|esquerda|miniaturadaimagem]]
[[Arquivo:Frum-bcop-fortaleza-2026 55178206816 o.jpg|nenhum|miniaturadaimagem]]

 
'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Usuário:Gondim

2026-04-01T20:13:33Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Fórum BCOP Fortaleza''' com a palestra: "'''Recomendações de segurança para provedores"''' com apresentação [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2487/Marcelo_Gondim_Recomendacoes_seguranca_provedores.pdf aqui] e vídeo [https://youtu.be/Qjgb7P3cG8k?t=9237 aqui]'''.''' Os arquivos anexos de configuração: [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2489/Marcelo_Gondim_filtros_edge_huawei.pdf filtros_edge_huawei], [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2490/spoofer.pdf spoofer] e [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2491/filtros_bng_huawei.pdf filtros_bng_huawei].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Moeda IX Fórum Fortaleza 2026:'''
[[Arquivo:Frum-bcop-fortaleza-2026 55178462504 o.jpg|esquerda|miniaturadaimagem]]
[[Arquivo:Frum-bcop-fortaleza-2026 55178206816 o.jpg|nenhum|miniaturadaimagem]]

'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Usuário:Gondim

2026-04-01T20:13:19Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Fórum BCOP Fortaleza''' com a palestra: "'''Recomendações de segurança para provedores"''' com apresentação [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2487/Marcelo_Gondim_Recomendacoes_seguranca_provedores.pdf aqui] e vídeo [https://youtu.be/Qjgb7P3cG8k?t=9237 aqui]'''.''' Os arquivos anexos de configuração: [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2489/Marcelo_Gondim_filtros_edge_huawei.pdf filtros_edge_huawei], [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2490/spoofer.pdf spoofer] e [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2491/filtros_bng_huawei.pdf filtros_bng_huawei].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Moeda IX Fórum Fortaleza 2026:'''
[[Arquivo:Frum-bcop-fortaleza-2026 55178462504 o.jpg|esquerda|miniaturadaimagem]]
[[Arquivo:Frum-bcop-fortaleza-2026 55178206816 o.jpg|nenhum|miniaturadaimagem]]
'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Arquivo:Frum-bcop-fortaleza-2026 55178206816 o.jpg

2026-04-01T20:12:59Z

Gondim:

Frum-bcop-fortaleza-2026 55178206816 o

Arquivo:Frum-bcop-fortaleza-2026 55178462504 o.jpg

2026-04-01T20:12:11Z

Gondim:

Frum-bcop-fortaleza-2026 55178462504 o

Usuário:Gondim

2026-04-01T20:11:12Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Fórum BCOP Fortaleza''' com a palestra: "'''Recomendações de segurança para provedores"''' com apresentação [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2487/Marcelo_Gondim_Recomendacoes_seguranca_provedores.pdf aqui] e vídeo [https://youtu.be/Qjgb7P3cG8k?t=9237 aqui]'''.''' Os arquivos anexos de configuração: [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2489/Marcelo_Gondim_filtros_edge_huawei.pdf filtros_edge_huawei], [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2490/spoofer.pdf spoofer] e [https://fortaleza.forumbcop.nic.br/files/apresentacao/arquivo/2491/filtros_bng_huawei.pdf filtros_bng_huawei].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Usuário:Gondim

2026-01-20T16:25:08Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Moeda recebida pelo NIC.br por contribuir com conhecimento palestrando na Semana de Infraestrutura da Internet no Brasil em 2025:'''
[[Arquivo:Moeda1.jpg|nenhum|miniaturadaimagem]]
'''Moeda comemorativa de 5 anos recebida pelo NIC.br em 2025 por contribuir com conhecimento para a Semana de Capacitação e Camada 8:'''
[[Arquivo:Moeda2.jpg|nenhum|miniaturadaimagem]]
'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Arquivo:Moeda2.jpg

2026-01-20T16:24:42Z

Gondim:

Moeda2

Arquivo:Moeda1.jpg

2026-01-20T16:23:43Z

Gondim:

Moeda1

DNS Recursivo Anycast Hyperlocal

2026-01-15T02:19:57Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop irqbalance

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:

https://github.com/NLnetLabs/unbound/issues/724
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desabilita Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-12-26T16:35:30Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:

https://github.com/NLnetLabs/unbound/issues/724
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desabilita Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-12-26T14:00:01Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:

https://github.com/NLnetLabs/unbound/issues/724
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desabilita Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-12-26T13:38:10Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data unbound-anchor
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:

https://github.com/NLnetLabs/unbound/issues/724
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desabilita Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

Usuário:Gondim

2025-12-24T12:14:12Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui] e vídeo [https://www.youtube.com/live/GnYK9UOLXr4?t=10257s aqui].

'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

Usuário:Gondim

2025-12-22T15:09:47Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Fórum BCOP-ICANN Edição Especial DNS''' com o painel "'''DNS em Ação: Como os provedores estão implantando as Boas Práticas"''' com '''apresentação''' [https://forumbcop.nic.br/files/apresentacao/arquivo/2428/DNS_KINDNS_Reduzido.pdf aqui]

'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

DNS Recursivo Anycast Hyperlocal

2025-11-24T15:01:15Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:

https://github.com/NLnetLabs/unbound/issues/724
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desabilita Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-11-24T14:59:16Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:

https://github.com/NLnetLabs/unbound/issues/724
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Ajusta Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-11-24T14:57:45Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Ajusta Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-11-24T14:44:13Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Ajustando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática ajustá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/ajusta-thp.service
[Unit]
Description=Ajusta Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo madvise > /sys/kernel/mm/transparent_hugepage/enabled"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''ajusta-thp.service''' para ajustar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now ajusta-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-11-22T17:00:47Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# rm /etc/apt/sources.list
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desativa Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-11-22T16:56:48Z

Gondim: atualização

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 8 cores
|16G DDR4
|30G
|Debian 13 amd64 (Trixie)
|}

== Softwares utilizados ==
* Debian 13 amd64 (Trixie) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list.d/debian.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://security.debian.org/debian-security/</nowiki>
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Deixe o arquivo '''/etc/apt/sources.list.d/debian-backports.sources''' conforme abaixo:
Types: deb
URIs: <nowiki>http://deb.debian.org/debian/</nowiki>
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.d/100-tuning.conf''' adicionamos essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x:
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desativa Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server.
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $(( ${TOTAL_NUM_QUERIES:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $(( ${TOTAL_NUM_CACHEHITS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $(( ${TOTAL_NUM_CACHEMISS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $(( ${TOTAL_NUM_PREFETCH:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $(( ${TOTAL_NUM_RECURSIVEREPLIES:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $(( ${TOTAL_REQ_MAX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $(( ${TOTAL_REQ_AVG:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $(( ${TOTAL_REQ_OVERWRITTEN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $(( ${TOTAL_REQ_EXCEEDED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $(( ${TOTAL_REQ_CURRENT_ALL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $(( ${TOTAL_REQ_CURRENT_USER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $(( ${TOTAL_TCPUSAGE:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $(( ${NUM_QUERY_TYPE_A:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $(( ${NUM_QUERY_TYPE_NS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $(( ${NUM_QUERY_TYPE_MX:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $(( ${NUM_QUERY_TYPE_TXT:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $(( ${NUM_QUERY_TYPE_PTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $(( ${NUM_QUERY_TYPE_AAAA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $(( ${NUM_QUERY_TYPE_SRV:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $(( ${NUM_QUERY_TYPE_SOA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $(( ${NUM_QUERY_TYPE_HTTPS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $(( ${NUM_QUERY_TYPE_TYPE0:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $(( ${NUM_QUERY_TYPE_CNAME:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $(( ${NUM_QUERY_TYPE_WKS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $(( ${NUM_QUERY_TYPE_HINFO:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $(( ${NUM_QUERY_TYPE_X25:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $(( ${NUM_QUERY_TYPE_NAPTR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $(( ${NUM_QUERY_TYPE_DS:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $(( ${NUM_QUERY_TYPE_DNSKEY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $(( ${NUM_QUERY_TYPE_TLSA:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $(( ${NUM_QUERY_TYPE_SVCB:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $(( ${NUM_QUERY_TYPE_SPF:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $(( ${NUM_QUERY_TYPE_ANY:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $(( ${NUM_QUERY_TYPE_OTHER:-0} / 300 ))

zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $(( ${NUM_ANSWER_RCODE_NOERROR:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $(( ${NUM_ANSWER_RCODE_NXDOMAIN:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $(( ${NUM_ANSWER_RCODE_SERVFAIL:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $(( ${NUM_ANSWER_RCODE_REFUSED:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $(( ${NUM_ANSWER_RCODE_nodata:-0} / 300 ))
zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $(( ${NUM_ANSWER_secure:-0} / 300 ))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
ospf6d=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.3
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 8
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 512m
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 1g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew --deploy-hook "/usr/sbin/unbound-control reload_keep_cache"
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

Usuário:Gondim

2025-10-28T11:49:18Z

Gondim:

'''Marcelo Gondim da Cunha'''
[[Arquivo:Gondim paisagem.jpg|esquerda|commoldura]]

'''Contribuições e trabalhos:'''

* Administração de Sistemas Unix-Like desde 1996.
* Consultor na Conectiva S/A - Unidade Rio em 2000.
** Autor do projeto TuxFrw - https://github.com/gondimcodes/tuxfrw e https://github.com/gondimcodes/tuxfrw-nft
* Administração de sistemas BSD pela FreeBSD Brasil em 2010.
* Direção do AS53135 - Nettel Telecomunicações entre 2003 e 2021 atingindo a marca de 41.000 assinantes. Gerando qualidade na entrega de serviços e implantando boas práticas como:

a) IPv6.

b) MANRS.

c) RPKI.

d) CPEs com firmware baseada na BCOP <nowiki>https://www.m3aawg.org/sites/default/files/lac-bcop-1-m3aawg-v1-portuguese-final.pdf</nowiki>
** SOC Specialist na Brasil TecPar (AS262907) de 2022 a 2025. Um milhão de clientes. Responsável pelas estratégias de mitigação anti-DDoS atendendo as Operações de RJ, SP, RS, SC, MT e MS.
'''Palestras ministradas:'''

* Semana da Informática UERJ 2002 - TuxFrw.
* CONISLI 2003 - TuxFrw.
* CONISLI 2004 - Fazendo compras com Gentoo Linux - Palestra sobre a distribuição Linux e suas ferramentas fantásticas.
* CONISLI 2004 - OpenVPN - Palestra sobre como criar VPNs seguras com OpenVPN e diferenças entre ele e o IPSec.
* CONISLI 2005 - SPoP (Security Point of Presence) com OpenVPN - Como utilizar túneis encriptados do OpenVPN para acessar a Internet de forma segura, onde quer que esteja.
* SECOMP 2005 UNIFEI - TuxFrw.

* Debconf19 2019 - [https://debconf19.debconf.org/talks/4-debian-na-vida-de-uma-operadora-de-telecom/ Debian na vida de uma operadora de Telecom], [https://www.youtube.com/watch?v=vQSTslUZy8k&list=PLYUtdmpYPTTJDtwgD8AtxzFJ9t_URhFMK&index=35 vídeo] e [https://salsa.debian.org/debconf-team/public/share/debconf19/raw/master/slides/4-debian-na-vida-de-uma-operadora-de-telecom.pdf?inline=false pdf].

* [https://www.youtube.com/watch?v=5uOFtkplDts FiqueEmCasaUseDebian - CGNAT com NFTables] e [https://www.youtube.com/watch?v=Wz2IAg6MMlU SysAdmin apps].

'''Artigos desenvolvidos para a comunidade do Brasil Peering Fórum:'''

* [https://wiki.brasilpeeringforum.org/w/CGNAT_na_pratica CGNAT na pratica].
* [https://wiki.brasilpeeringforum.org/w/Acesso_via_IPv6_Link-Local Acesso via IPv6 Link-Local].
* [https://wiki.brasilpeeringforum.org/w/MANRS MANRS].
* [https://wiki.brasilpeeringforum.org/w/CGNAT_Bulk_Port_Allocation_com_DPDK CGNAT Bulk Port Allocation com DPDK].
* [https://wiki.brasilpeeringforum.org/w/Servidor_de_Logs Servidor de Logs].
* [[DNS Recursivo Anycast Hyperlocal|DNS Anycast com Hyperlocal]].
* [[Recomendações sobre Mitigação DDoS]]
* [[Portas de Amplificação DDoS e Botnets]]
* [[Static Loop - um erro que pode matar seu ISP/ITP]]
* [[Identificando e neutralizando uma Botnet]]

'''Tutorial:'''

* [https://bit.ly/2saumHK Segurança de roteamento: MANRS (Mutually Agreed Norms for Routing Security) - Tutoriais NIC.br em 09/12/2019].

'''[https://www.manrs.org/about/advisory-group/members/ MANRS Advisory Group Member (2020-2021)]'''.

[https://www.youtube.com/watch?v=oahQkGx8urY '''Live sobre MANRS com Leonardo Furtado'''].

Criação da Wiki ISPUP! em 24/12/2022.

'''Semana de Capacitação 6 do NIC.br 28/04/2023''' - "'''CONCEITOS E IMPLEMENTAÇÃO DE CGNAT'''". Material [https://semanacap.bcp.nic.br/6-online/ aqui] e vídeo aula [https://www.youtube.com/watch?v=1q7J3NkQVSc aqui].

'''Semana de Capacitação 10 do NIC.br 01/07/2025''' - "'''Teste para padrões técnicos modernos de Internet e segurança: IPv6, DNSSEC, TLS, HTTPS e HSTS'''"'''.''' Material [https://semanacap.bcp.nic.br/semana-de-capacitacao-online-edicao-10-2025/ aqui] e vídeo aula [https://www.youtube.com/watch?v=55RBnGQhi2o aqui].

'''IX Fórum Regional Sudeste (Rio de Janeiro) 24/10/2025''' com a palestra "'''Segurança com o pé direito'''" pode ser baixada [https://regional.forum.ix.br/files/apresentacao/arquivo/2307/gondim.pdf aqui].

'''Webinar:'''

Proteção e Mitigação de ataques DDoS em 10/09/2024 às 20:00 UTC -3. Site da chamada [https://gdg.community.dev/events/details/google-gdg-sinop-presents-webinar-ao-vivo-protecao-e-mitigacao-de-ataques-ddos/ aqui] e o vídeo da live no Youtube [https://www.youtube.com/live/7VIaoDQaLQE aqui].

'''Podcast:'''

[https://www.youtube.com/live/x4fxtma4eyQ Segurança de Rede e Infraestrutura para 2025: Preparando os ISPs para o futuro!]

'''Contatos:'''

Telegram: '''@Marcelo_Gondim'''

WhatsApp: +55 (22) 99743-9060

E-mail: '''gondim at ispup.com.br'''

Linkedin: https://www.linkedin.com/in/marcelo-gondim-sysadmin/

Meu Github: https://github.com/gondimcodes

== Mini-CV ==
'''Marcelo Gondim''' começou sua carreira como desenvolvedor de software em COBOL e Clipper entre 1992 e 1995. Em 1996 foi responsável por desenvolver um sistema concorrente com o RENPAC da Embratel para acesso ao SISCOMEX e implantou a Internet para fins comerciais na empresa DATABRAS. Trabalhou como consultor e instrutor de GNU/Linux na Conectiva S/A em 2000. Em 2003 se tornou consultor de diversos Provedores de Internet na Região dos Lagos - RJ e onde acabou se tornando CTO da Nettel Telecomunicações (AS53135) com 42.000 assinantes. Implantou IPv6 iniciando em 2013 e se tornou participante do MANRS com diversas contribuições com artigos e palestras. Trabalhou como Especialista em Redes e SOC (Security Operations Center) na Brasil TecPar AS262907 entre 2022 e 2025, onde implementou boas práticas, tratamentos de incidentes relacionados ao ASN, desenvolveu as estratégias de Mitigação DDoS e uma Rede de DNS Recursivo Anycast espalhada pelo RS, RJ, SP, SC MT e MS, também certificada KINDNS. Fundador da empresa ISPFocus especializada em Tecnologia da Informação e boas práticas para ISPs.

DNS Recursivo Anycast Hyperlocal

2025-09-16T02:24:25Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fd00::10:10:10:10/128'''

'''10.10.9.9/32 - fd00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 4 cores
|16G DDR4
|30G
|Debian 12 amd64 (Bookworm)
|}

== Softwares utilizados ==
* Debian 12 amd64 (Bookworm) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list''' conforme abaixo:
deb <nowiki>http://security.debian.org/debian-security</nowiki> bookworm-security main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-updates main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-backports main contrib non-free non-free-firmware
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.conf''' adicionamos no final do arquivo essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x e para isso precisaremos configurar o repositório oficial do FRRouting e instalar os pacotes:
# curl -s <nowiki>https://deb.frrouting.org/frr/keys.gpg</nowiki> | tee /usr/share/keyrings/frrouting.gpg > /dev/null
# echo "deb [signed-by=/usr/share/keyrings/frrouting.gpg] <nowiki>https://deb.frrouting.org/frr</nowiki> bookworm frr-10" > /etc/apt/sources.list.d/frr.list
# apt update
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desativa Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server, if variables is not empty!
[ -z ${TOTAL_NUM_QUERIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $((TOTAL_NUM_QUERIES/300))
[ -z ${TOTAL_NUM_CACHEHITS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $((TOTAL_NUM_CACHEHITS/300))
[ -z ${TOTAL_NUM_CACHEMISS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $((TOTAL_NUM_CACHEMISS/300))
[ -z ${TOTAL_NUM_PREFETCH} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $((TOTAL_NUM_PREFETCH/300))
[ -z ${TOTAL_NUM_RECURSIVEREPLIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $((TOTAL_NUM_RECURSIVEREPLIES/300))

[ -z ${TOTAL_REQ_MAX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $((TOTAL_REQ_MAX/300))
[ -z ${TOTAL_REQ_AVG} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $((TOTAL_REQ_AVG/300))
[ -z ${TOTAL_REQ_OVERWRITTEN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $((TOTAL_REQ_OVERWRITTEN/300))
[ -z ${TOTAL_REQ_EXCEEDED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $((TOTAL_REQ_EXCEEDED/300))
[ -z ${TOTAL_REQ_CURRENT_ALL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $((TOTAL_REQ_CURRENT_ALL/300))
[ -z ${TOTAL_REQ_CURRENT_USER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $((TOTAL_REQ_CURRENT_USER/300))

[ -z ${TOTAL_TCPUSAGE} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $((TOTAL_TCPUSAGE/300))

[ -z ${NUM_QUERY_TYPE_A} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $((NUM_QUERY_TYPE_A/300))
[ -z ${NUM_QUERY_TYPE_NS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $((NUM_QUERY_TYPE_NS/300))
[ -z ${NUM_QUERY_TYPE_MX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $((NUM_QUERY_TYPE_MX/300))
[ -z ${NUM_QUERY_TYPE_TXT} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $((NUM_QUERY_TYPE_TXT/300))
[ -z ${NUM_QUERY_TYPE_PTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $((NUM_QUERY_TYPE_PTR/300))
[ -z ${NUM_QUERY_TYPE_AAAA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $((NUM_QUERY_TYPE_AAAA/300))
[ -z ${NUM_QUERY_TYPE_SRV} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $((NUM_QUERY_TYPE_SRV/300))
[ -z ${NUM_QUERY_TYPE_SOA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $((NUM_QUERY_TYPE_SOA/300))
[ -z ${NUM_QUERY_TYPE_HTTPS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $((NUM_QUERY_TYPE_HTTPS/300))
[ -z ${NUM_QUERY_TYPE_TYPE0} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $((NUM_QUERY_TYPE_TYPE0/300))
[ -z ${NUM_QUERY_TYPE_CNAME} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $((NUM_QUERY_TYPE_CNAME/300))
[ -z ${NUM_QUERY_TYPE_WKS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $((NUM_QUERY_TYPE_WKS/300))
[ -z ${NUM_QUERY_TYPE_HINFO} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $((NUM_QUERY_TYPE_HINFO/300))
[ -z ${NUM_QUERY_TYPE_X25} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $((NUM_QUERY_TYPE_X25/300))
[ -z ${NUM_QUERY_TYPE_NAPTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $((NUM_QUERY_TYPE_NAPTR/300))
[ -z ${NUM_QUERY_TYPE_DS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $((NUM_QUERY_TYPE_DS/300))
[ -z ${NUM_QUERY_TYPE_DNSKEY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $((NUM_QUERY_TYPE_DNSKEY/300))
[ -z ${NUM_QUERY_TYPE_TLSA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $((NUM_QUERY_TYPE_TLSA/300))
[ -z ${NUM_QUERY_TYPE_SVCB} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $((NUM_QUERY_TYPE_SVCB/300))
[ -z ${NUM_QUERY_TYPE_SPF} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $((NUM_QUERY_TYPE_SPF/300))
[ -z ${NUM_QUERY_TYPE_ANY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $((NUM_QUERY_TYPE_ANY/300))
[ -z ${NUM_QUERY_TYPE_OTHER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $((NUM_QUERY_TYPE_OTHER/300))

[ -z ${NUM_ANSWER_RCODE_NOERROR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $((NUM_ANSWER_RCODE_NOERROR/300))
[ -z ${NUM_ANSWER_RCODE_NXDOMAIN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $((NUM_ANSWER_RCODE_NXDOMAIN/300))
[ -z ${NUM_ANSWER_RCODE_SERVFAIL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $((NUM_ANSWER_RCODE_SERVFAIL/300))
[ -z ${NUM_ANSWER_RCODE_REFUSED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $((NUM_ANSWER_RCODE_REFUSED/300))
[ -z ${NUM_ANSWER_RCODE_nodata} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $((NUM_ANSWER_RCODE_nodata/300))
[ -z ${NUM_ANSWER_secure} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $((NUM_ANSWER_secure/300))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.2.1
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 1g
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 2g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10 e fd00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-09-16T02:22:45Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Recursivo99.png|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fc00::10:10:10:10/128'''

'''10.10.9.9/32 - fc00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 4 cores
|16G DDR4
|30G
|Debian 12 amd64 (Bookworm)
|}

== Softwares utilizados ==
* Debian 12 amd64 (Bookworm) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fd00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fd00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fd00::10:10:10:10''' e '''fd00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list''' conforme abaixo:
deb <nowiki>http://security.debian.org/debian-security</nowiki> bookworm-security main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-updates main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-backports main contrib non-free non-free-firmware
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.conf''' adicionamos no final do arquivo essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x e para isso precisaremos configurar o repositório oficial do FRRouting e instalar os pacotes:
# curl -s <nowiki>https://deb.frrouting.org/frr/keys.gpg</nowiki> | tee /usr/share/keyrings/frrouting.gpg > /dev/null
# echo "deb [signed-by=/usr/share/keyrings/frrouting.gpg] <nowiki>https://deb.frrouting.org/frr</nowiki> bookworm frr-10" > /etc/apt/sources.list.d/frr.list
# apt update
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desativa Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server, if variables is not empty!
[ -z ${TOTAL_NUM_QUERIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $((TOTAL_NUM_QUERIES/300))
[ -z ${TOTAL_NUM_CACHEHITS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $((TOTAL_NUM_CACHEHITS/300))
[ -z ${TOTAL_NUM_CACHEMISS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $((TOTAL_NUM_CACHEMISS/300))
[ -z ${TOTAL_NUM_PREFETCH} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $((TOTAL_NUM_PREFETCH/300))
[ -z ${TOTAL_NUM_RECURSIVEREPLIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $((TOTAL_NUM_RECURSIVEREPLIES/300))

[ -z ${TOTAL_REQ_MAX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $((TOTAL_REQ_MAX/300))
[ -z ${TOTAL_REQ_AVG} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $((TOTAL_REQ_AVG/300))
[ -z ${TOTAL_REQ_OVERWRITTEN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $((TOTAL_REQ_OVERWRITTEN/300))
[ -z ${TOTAL_REQ_EXCEEDED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $((TOTAL_REQ_EXCEEDED/300))
[ -z ${TOTAL_REQ_CURRENT_ALL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $((TOTAL_REQ_CURRENT_ALL/300))
[ -z ${TOTAL_REQ_CURRENT_USER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $((TOTAL_REQ_CURRENT_USER/300))

[ -z ${TOTAL_TCPUSAGE} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $((TOTAL_TCPUSAGE/300))

[ -z ${NUM_QUERY_TYPE_A} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $((NUM_QUERY_TYPE_A/300))
[ -z ${NUM_QUERY_TYPE_NS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $((NUM_QUERY_TYPE_NS/300))
[ -z ${NUM_QUERY_TYPE_MX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $((NUM_QUERY_TYPE_MX/300))
[ -z ${NUM_QUERY_TYPE_TXT} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $((NUM_QUERY_TYPE_TXT/300))
[ -z ${NUM_QUERY_TYPE_PTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $((NUM_QUERY_TYPE_PTR/300))
[ -z ${NUM_QUERY_TYPE_AAAA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $((NUM_QUERY_TYPE_AAAA/300))
[ -z ${NUM_QUERY_TYPE_SRV} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $((NUM_QUERY_TYPE_SRV/300))
[ -z ${NUM_QUERY_TYPE_SOA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $((NUM_QUERY_TYPE_SOA/300))
[ -z ${NUM_QUERY_TYPE_HTTPS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $((NUM_QUERY_TYPE_HTTPS/300))
[ -z ${NUM_QUERY_TYPE_TYPE0} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $((NUM_QUERY_TYPE_TYPE0/300))
[ -z ${NUM_QUERY_TYPE_CNAME} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $((NUM_QUERY_TYPE_CNAME/300))
[ -z ${NUM_QUERY_TYPE_WKS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $((NUM_QUERY_TYPE_WKS/300))
[ -z ${NUM_QUERY_TYPE_HINFO} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $((NUM_QUERY_TYPE_HINFO/300))
[ -z ${NUM_QUERY_TYPE_X25} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $((NUM_QUERY_TYPE_X25/300))
[ -z ${NUM_QUERY_TYPE_NAPTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $((NUM_QUERY_TYPE_NAPTR/300))
[ -z ${NUM_QUERY_TYPE_DS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $((NUM_QUERY_TYPE_DS/300))
[ -z ${NUM_QUERY_TYPE_DNSKEY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $((NUM_QUERY_TYPE_DNSKEY/300))
[ -z ${NUM_QUERY_TYPE_TLSA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $((NUM_QUERY_TYPE_TLSA/300))
[ -z ${NUM_QUERY_TYPE_SVCB} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $((NUM_QUERY_TYPE_SVCB/300))
[ -z ${NUM_QUERY_TYPE_SPF} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $((NUM_QUERY_TYPE_SPF/300))
[ -z ${NUM_QUERY_TYPE_ANY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $((NUM_QUERY_TYPE_ANY/300))
[ -z ${NUM_QUERY_TYPE_OTHER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $((NUM_QUERY_TYPE_OTHER/300))

[ -z ${NUM_ANSWER_RCODE_NOERROR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $((NUM_ANSWER_RCODE_NOERROR/300))
[ -z ${NUM_ANSWER_RCODE_NXDOMAIN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $((NUM_ANSWER_RCODE_NXDOMAIN/300))
[ -z ${NUM_ANSWER_RCODE_SERVFAIL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $((NUM_ANSWER_RCODE_SERVFAIL/300))
[ -z ${NUM_ANSWER_RCODE_REFUSED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $((NUM_ANSWER_RCODE_REFUSED/300))
[ -z ${NUM_ANSWER_RCODE_nodata} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $((NUM_ANSWER_RCODE_nodata/300))
[ -z ${NUM_ANSWER_secure} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $((NUM_ANSWER_secure/300))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.2.1
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fd00::10:10:10:10
interface: fd00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 1g
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 2g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) - opcional ==
Para habilitar o '''DoH''' no Unbound é bem simples. O recurso do '''DoH''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fd00::10:10:10:10@443
interface: fd00::10:10:9:9@443
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

Arquivo:Recursivo99.png

2025-09-16T02:20:01Z

Gondim:

recursivo99

DNS Recursivo Anycast Hyperlocal

2025-09-14T13:27:05Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Diagrama dns recursiv2.png|alt=|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fc00::10:10:10:10/128'''

'''10.10.9.9/32 - fc00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 4 cores
|16G DDR4
|30G
|Debian 12 amd64 (Bookworm)
|}

== Softwares utilizados ==
* Debian 12 amd64 (Bookworm) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fc00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fc00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10''' e '''fc00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list''' conforme abaixo:
deb <nowiki>http://security.debian.org/debian-security</nowiki> bookworm-security main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-updates main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-backports main contrib non-free non-free-firmware
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.conf''' adicionamos no final do arquivo essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x e para isso precisaremos configurar o repositório oficial do FRRouting e instalar os pacotes:
# curl -s <nowiki>https://deb.frrouting.org/frr/keys.gpg</nowiki> | tee /usr/share/keyrings/frrouting.gpg > /dev/null
# echo "deb [signed-by=/usr/share/keyrings/frrouting.gpg] <nowiki>https://deb.frrouting.org/frr</nowiki> bookworm frr-10" > /etc/apt/sources.list.d/frr.list
# apt update
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desativa Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server, if variables is not empty!
[ -z ${TOTAL_NUM_QUERIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $((TOTAL_NUM_QUERIES/300))
[ -z ${TOTAL_NUM_CACHEHITS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $((TOTAL_NUM_CACHEHITS/300))
[ -z ${TOTAL_NUM_CACHEMISS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $((TOTAL_NUM_CACHEMISS/300))
[ -z ${TOTAL_NUM_PREFETCH} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $((TOTAL_NUM_PREFETCH/300))
[ -z ${TOTAL_NUM_RECURSIVEREPLIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $((TOTAL_NUM_RECURSIVEREPLIES/300))

[ -z ${TOTAL_REQ_MAX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $((TOTAL_REQ_MAX/300))
[ -z ${TOTAL_REQ_AVG} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $((TOTAL_REQ_AVG/300))
[ -z ${TOTAL_REQ_OVERWRITTEN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $((TOTAL_REQ_OVERWRITTEN/300))
[ -z ${TOTAL_REQ_EXCEEDED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $((TOTAL_REQ_EXCEEDED/300))
[ -z ${TOTAL_REQ_CURRENT_ALL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $((TOTAL_REQ_CURRENT_ALL/300))
[ -z ${TOTAL_REQ_CURRENT_USER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $((TOTAL_REQ_CURRENT_USER/300))

[ -z ${TOTAL_TCPUSAGE} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $((TOTAL_TCPUSAGE/300))

[ -z ${NUM_QUERY_TYPE_A} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $((NUM_QUERY_TYPE_A/300))
[ -z ${NUM_QUERY_TYPE_NS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $((NUM_QUERY_TYPE_NS/300))
[ -z ${NUM_QUERY_TYPE_MX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $((NUM_QUERY_TYPE_MX/300))
[ -z ${NUM_QUERY_TYPE_TXT} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $((NUM_QUERY_TYPE_TXT/300))
[ -z ${NUM_QUERY_TYPE_PTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $((NUM_QUERY_TYPE_PTR/300))
[ -z ${NUM_QUERY_TYPE_AAAA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $((NUM_QUERY_TYPE_AAAA/300))
[ -z ${NUM_QUERY_TYPE_SRV} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $((NUM_QUERY_TYPE_SRV/300))
[ -z ${NUM_QUERY_TYPE_SOA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $((NUM_QUERY_TYPE_SOA/300))
[ -z ${NUM_QUERY_TYPE_HTTPS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $((NUM_QUERY_TYPE_HTTPS/300))
[ -z ${NUM_QUERY_TYPE_TYPE0} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $((NUM_QUERY_TYPE_TYPE0/300))
[ -z ${NUM_QUERY_TYPE_CNAME} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $((NUM_QUERY_TYPE_CNAME/300))
[ -z ${NUM_QUERY_TYPE_WKS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $((NUM_QUERY_TYPE_WKS/300))
[ -z ${NUM_QUERY_TYPE_HINFO} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $((NUM_QUERY_TYPE_HINFO/300))
[ -z ${NUM_QUERY_TYPE_X25} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $((NUM_QUERY_TYPE_X25/300))
[ -z ${NUM_QUERY_TYPE_NAPTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $((NUM_QUERY_TYPE_NAPTR/300))
[ -z ${NUM_QUERY_TYPE_DS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $((NUM_QUERY_TYPE_DS/300))
[ -z ${NUM_QUERY_TYPE_DNSKEY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $((NUM_QUERY_TYPE_DNSKEY/300))
[ -z ${NUM_QUERY_TYPE_TLSA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $((NUM_QUERY_TYPE_TLSA/300))
[ -z ${NUM_QUERY_TYPE_SVCB} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $((NUM_QUERY_TYPE_SVCB/300))
[ -z ${NUM_QUERY_TYPE_SPF} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $((NUM_QUERY_TYPE_SPF/300))
[ -z ${NUM_QUERY_TYPE_ANY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $((NUM_QUERY_TYPE_ANY/300))
[ -z ${NUM_QUERY_TYPE_OTHER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $((NUM_QUERY_TYPE_OTHER/300))

[ -z ${NUM_ANSWER_RCODE_NOERROR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $((NUM_ANSWER_RCODE_NOERROR/300))
[ -z ${NUM_ANSWER_RCODE_NXDOMAIN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $((NUM_ANSWER_RCODE_NXDOMAIN/300))
[ -z ${NUM_ANSWER_RCODE_SERVFAIL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $((NUM_ANSWER_RCODE_SERVFAIL/300))
[ -z ${NUM_ANSWER_RCODE_REFUSED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $((NUM_ANSWER_RCODE_REFUSED/300))
[ -z ${NUM_ANSWER_RCODE_nodata} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $((NUM_ANSWER_RCODE_nodata/300))
[ -z ${NUM_ANSWER_secure} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $((NUM_ANSWER_secure/300))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Mantendo a hora certa ==
Vamos instalar agora o Chrony para manter a data e hora certas no sistema:
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.2.1
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fc00::10:10:10:10
interface: fc00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 1g
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 2g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) e DoT (DNS over TLS) - opcional ==
Para habilitar o '''DoH''' e o '''DoT''' no Unbound é bem simples. O recurso do '''DoH''' e '''DoT''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fc00::10:10:10:10@443
interface: fc00::10:10:9:9@443
interface: 10.10.10.10@853
interface: 10.10.9.9@853
interface: fc00::10:10:10:10@853
interface: fc00::10:10:9:9@853
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-09-01T18:47:22Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Diagrama dns recursiv2.png|alt=|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fc00::10:10:10:10/128'''

'''10.10.9.9/32 - fc00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 4 cores
|16G DDR4
|30G
|Debian 12 amd64 (Bookworm)
|}

== Softwares utilizados ==
* Debian 12 amd64 (Bookworm) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* IRQBalance.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fc00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fc00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10''' e '''fc00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list''' conforme abaixo:
deb <nowiki>http://security.debian.org/debian-security</nowiki> bookworm-security main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-updates main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-backports main contrib non-free non-free-firmware
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.conf''' adicionamos no final do arquivo essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x e para isso precisaremos configurar o repositório oficial do FRRouting e instalar os pacotes:
# curl -s <nowiki>https://deb.frrouting.org/frr/keys.gpg</nowiki> | tee /usr/share/keyrings/frrouting.gpg > /dev/null
# echo "deb [signed-by=/usr/share/keyrings/frrouting.gpg] <nowiki>https://deb.frrouting.org/frr</nowiki> bookworm frr-10" > /etc/apt/sources.list.d/frr.list
# apt update
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desativa Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server, if variables is not empty!
[ -z ${TOTAL_NUM_QUERIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $((TOTAL_NUM_QUERIES/300))
[ -z ${TOTAL_NUM_CACHEHITS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $((TOTAL_NUM_CACHEHITS/300))
[ -z ${TOTAL_NUM_CACHEMISS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $((TOTAL_NUM_CACHEMISS/300))
[ -z ${TOTAL_NUM_PREFETCH} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $((TOTAL_NUM_PREFETCH/300))
[ -z ${TOTAL_NUM_RECURSIVEREPLIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $((TOTAL_NUM_RECURSIVEREPLIES/300))

[ -z ${TOTAL_REQ_MAX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $((TOTAL_REQ_MAX/300))
[ -z ${TOTAL_REQ_AVG} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $((TOTAL_REQ_AVG/300))
[ -z ${TOTAL_REQ_OVERWRITTEN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $((TOTAL_REQ_OVERWRITTEN/300))
[ -z ${TOTAL_REQ_EXCEEDED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $((TOTAL_REQ_EXCEEDED/300))
[ -z ${TOTAL_REQ_CURRENT_ALL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $((TOTAL_REQ_CURRENT_ALL/300))
[ -z ${TOTAL_REQ_CURRENT_USER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $((TOTAL_REQ_CURRENT_USER/300))

[ -z ${TOTAL_TCPUSAGE} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $((TOTAL_TCPUSAGE/300))

[ -z ${NUM_QUERY_TYPE_A} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $((NUM_QUERY_TYPE_A/300))
[ -z ${NUM_QUERY_TYPE_NS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $((NUM_QUERY_TYPE_NS/300))
[ -z ${NUM_QUERY_TYPE_MX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $((NUM_QUERY_TYPE_MX/300))
[ -z ${NUM_QUERY_TYPE_TXT} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $((NUM_QUERY_TYPE_TXT/300))
[ -z ${NUM_QUERY_TYPE_PTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $((NUM_QUERY_TYPE_PTR/300))
[ -z ${NUM_QUERY_TYPE_AAAA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $((NUM_QUERY_TYPE_AAAA/300))
[ -z ${NUM_QUERY_TYPE_SRV} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $((NUM_QUERY_TYPE_SRV/300))
[ -z ${NUM_QUERY_TYPE_SOA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $((NUM_QUERY_TYPE_SOA/300))
[ -z ${NUM_QUERY_TYPE_HTTPS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $((NUM_QUERY_TYPE_HTTPS/300))
[ -z ${NUM_QUERY_TYPE_TYPE0} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $((NUM_QUERY_TYPE_TYPE0/300))
[ -z ${NUM_QUERY_TYPE_CNAME} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $((NUM_QUERY_TYPE_CNAME/300))
[ -z ${NUM_QUERY_TYPE_WKS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $((NUM_QUERY_TYPE_WKS/300))
[ -z ${NUM_QUERY_TYPE_HINFO} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $((NUM_QUERY_TYPE_HINFO/300))
[ -z ${NUM_QUERY_TYPE_X25} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $((NUM_QUERY_TYPE_X25/300))
[ -z ${NUM_QUERY_TYPE_NAPTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $((NUM_QUERY_TYPE_NAPTR/300))
[ -z ${NUM_QUERY_TYPE_DS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $((NUM_QUERY_TYPE_DS/300))
[ -z ${NUM_QUERY_TYPE_DNSKEY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $((NUM_QUERY_TYPE_DNSKEY/300))
[ -z ${NUM_QUERY_TYPE_TLSA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $((NUM_QUERY_TYPE_TLSA/300))
[ -z ${NUM_QUERY_TYPE_SVCB} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $((NUM_QUERY_TYPE_SVCB/300))
[ -z ${NUM_QUERY_TYPE_SPF} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $((NUM_QUERY_TYPE_SPF/300))
[ -z ${NUM_QUERY_TYPE_ANY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $((NUM_QUERY_TYPE_ANY/300))
[ -z ${NUM_QUERY_TYPE_OTHER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $((NUM_QUERY_TYPE_OTHER/300))

[ -z ${NUM_ANSWER_RCODE_NOERROR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $((NUM_ANSWER_RCODE_NOERROR/300))
[ -z ${NUM_ANSWER_RCODE_NXDOMAIN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $((NUM_ANSWER_RCODE_NXDOMAIN/300))
[ -z ${NUM_ANSWER_RCODE_SERVFAIL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $((NUM_ANSWER_RCODE_SERVFAIL/300))
[ -z ${NUM_ANSWER_RCODE_REFUSED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $((NUM_ANSWER_RCODE_REFUSED/300))
[ -z ${NUM_ANSWER_RCODE_nodata} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $((NUM_ANSWER_RCODE_nodata/300))
[ -z ${NUM_ANSWER_secure} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $((NUM_ANSWER_secure/300))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Balanceando o processamento e mantendo a hora certa ==
Vamos instalar 2 programas agora, o IRQBalance e o Chrony. O primeiro para balancear a carga entre os cores e o segundo para manter a data e hora certas no sistema:
# apt install irqbalance
# systemctl enable irqbalance
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.2.1
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fc00::10:10:10:10
interface: fc00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 1g
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 2g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
unbound-control flush $site &> /dev/null
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) e DoT (DNS over TLS) - opcional ==
Para habilitar o '''DoH''' e o '''DoT''' no Unbound é bem simples. O recurso do '''DoH''' e '''DoT''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fc00::10:10:10:10@443
interface: fc00::10:10:9:9@443
interface: 10.10.10.10@853
interface: 10.10.9.9@853
interface: fc00::10:10:10:10@853
interface: fc00::10:10:9:9@853
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-07-19T20:23:42Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Diagrama dns recursiv2.png|alt=|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fc00::10:10:10:10/128'''

'''10.10.9.9/32 - fc00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 4 cores
|16G DDR4
|30G
|Debian 12 amd64 (Bookworm)
|}

== Softwares utilizados ==
* Debian 12 amd64 (Bookworm) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* IRQBalance.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fc00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fc00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10''' e '''fc00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list''' conforme abaixo:
deb <nowiki>http://security.debian.org/debian-security</nowiki> bookworm-security main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-updates main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-backports main contrib non-free non-free-firmware
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.conf''' adicionamos no final do arquivo essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x e para isso precisaremos configurar o repositório oficial do FRRouting e instalar os pacotes:
# curl -s <nowiki>https://deb.frrouting.org/frr/keys.gpg</nowiki> | tee /usr/share/keyrings/frrouting.gpg > /dev/null
# echo "deb [signed-by=/usr/share/keyrings/frrouting.gpg] <nowiki>https://deb.frrouting.org/frr</nowiki> bookworm frr-10" > /etc/apt/sources.list.d/frr.list
# apt update
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Desabilitando THP (Transparente Huge Pages) em arquitetura AMD64 ==
No Debian o '''THP''' vem habilitado como '''always''' e o '''unbound''' por trabalhar bastante com alterações do cache em memória, isso pode acabar causando um consumo crescente de uso de RAM sem necessidade. É uma boa prática desabilitá-lo com os passos abaixo:
cat << EOF > /etc/systemd/system/disable-thp.service
[Unit]
Description=Desativa Transparent Huge Pages (THP)
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
Acima configuramos o serviço '''disable-thp.service''' para desabilitar o '''THP''' e abaixo habilitamos no '''systemd''' e iniciamos:
# systemctl daemon-reload
# systemctl enable --now disable-thp

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server, if variables is not empty!
[ -z ${TOTAL_NUM_QUERIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $((TOTAL_NUM_QUERIES/300))
[ -z ${TOTAL_NUM_CACHEHITS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $((TOTAL_NUM_CACHEHITS/300))
[ -z ${TOTAL_NUM_CACHEMISS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $((TOTAL_NUM_CACHEMISS/300))
[ -z ${TOTAL_NUM_PREFETCH} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $((TOTAL_NUM_PREFETCH/300))
[ -z ${TOTAL_NUM_RECURSIVEREPLIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $((TOTAL_NUM_RECURSIVEREPLIES/300))

[ -z ${TOTAL_REQ_MAX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $((TOTAL_REQ_MAX/300))
[ -z ${TOTAL_REQ_AVG} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $((TOTAL_REQ_AVG/300))
[ -z ${TOTAL_REQ_OVERWRITTEN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $((TOTAL_REQ_OVERWRITTEN/300))
[ -z ${TOTAL_REQ_EXCEEDED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $((TOTAL_REQ_EXCEEDED/300))
[ -z ${TOTAL_REQ_CURRENT_ALL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $((TOTAL_REQ_CURRENT_ALL/300))
[ -z ${TOTAL_REQ_CURRENT_USER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $((TOTAL_REQ_CURRENT_USER/300))

[ -z ${TOTAL_TCPUSAGE} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $((TOTAL_TCPUSAGE/300))

[ -z ${NUM_QUERY_TYPE_A} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $((NUM_QUERY_TYPE_A/300))
[ -z ${NUM_QUERY_TYPE_NS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $((NUM_QUERY_TYPE_NS/300))
[ -z ${NUM_QUERY_TYPE_MX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $((NUM_QUERY_TYPE_MX/300))
[ -z ${NUM_QUERY_TYPE_TXT} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $((NUM_QUERY_TYPE_TXT/300))
[ -z ${NUM_QUERY_TYPE_PTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $((NUM_QUERY_TYPE_PTR/300))
[ -z ${NUM_QUERY_TYPE_AAAA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $((NUM_QUERY_TYPE_AAAA/300))
[ -z ${NUM_QUERY_TYPE_SRV} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $((NUM_QUERY_TYPE_SRV/300))
[ -z ${NUM_QUERY_TYPE_SOA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $((NUM_QUERY_TYPE_SOA/300))
[ -z ${NUM_QUERY_TYPE_HTTPS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $((NUM_QUERY_TYPE_HTTPS/300))
[ -z ${NUM_QUERY_TYPE_TYPE0} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $((NUM_QUERY_TYPE_TYPE0/300))
[ -z ${NUM_QUERY_TYPE_CNAME} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $((NUM_QUERY_TYPE_CNAME/300))
[ -z ${NUM_QUERY_TYPE_WKS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $((NUM_QUERY_TYPE_WKS/300))
[ -z ${NUM_QUERY_TYPE_HINFO} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $((NUM_QUERY_TYPE_HINFO/300))
[ -z ${NUM_QUERY_TYPE_X25} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $((NUM_QUERY_TYPE_X25/300))
[ -z ${NUM_QUERY_TYPE_NAPTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $((NUM_QUERY_TYPE_NAPTR/300))
[ -z ${NUM_QUERY_TYPE_DS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $((NUM_QUERY_TYPE_DS/300))
[ -z ${NUM_QUERY_TYPE_DNSKEY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $((NUM_QUERY_TYPE_DNSKEY/300))
[ -z ${NUM_QUERY_TYPE_TLSA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $((NUM_QUERY_TYPE_TLSA/300))
[ -z ${NUM_QUERY_TYPE_SVCB} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $((NUM_QUERY_TYPE_SVCB/300))
[ -z ${NUM_QUERY_TYPE_SPF} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $((NUM_QUERY_TYPE_SPF/300))
[ -z ${NUM_QUERY_TYPE_ANY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $((NUM_QUERY_TYPE_ANY/300))
[ -z ${NUM_QUERY_TYPE_OTHER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $((NUM_QUERY_TYPE_OTHER/300))

[ -z ${NUM_ANSWER_RCODE_NOERROR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $((NUM_ANSWER_RCODE_NOERROR/300))
[ -z ${NUM_ANSWER_RCODE_NXDOMAIN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $((NUM_ANSWER_RCODE_NXDOMAIN/300))
[ -z ${NUM_ANSWER_RCODE_SERVFAIL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $((NUM_ANSWER_RCODE_SERVFAIL/300))
[ -z ${NUM_ANSWER_RCODE_REFUSED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $((NUM_ANSWER_RCODE_REFUSED/300))
[ -z ${NUM_ANSWER_RCODE_nodata} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $((NUM_ANSWER_RCODE_nodata/300))
[ -z ${NUM_ANSWER_secure} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $((NUM_ANSWER_secure/300))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Balanceando o processamento e mantendo a hora certa ==
Vamos instalar 2 programas agora, o IRQBalance e o Chrony. O primeiro para balancear a carga entre os cores e o segundo para manter a data e hora certas no sistema:
# apt install irqbalance
# systemctl enable irqbalance
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.2.1
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fc00::10:10:10:10
interface: fc00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 1g
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 2g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) e DoT (DNS over TLS) - opcional ==
Para habilitar o '''DoH''' e o '''DoT''' no Unbound é bem simples. O recurso do '''DoH''' e '''DoT''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fc00::10:10:10:10@443
interface: fc00::10:10:9:9@443
interface: 10.10.10.10@853
interface: 10.10.9.9@853
interface: fc00::10:10:10:10@853
interface: fc00::10:10:9:9@853
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__

DNS Recursivo Anycast Hyperlocal

2025-07-18T02:49:55Z

Gondim:

__TOC__
==Introdução==
Você sabe como funciona a Internet? Essa é uma pergunta que meu amigo '''Thiago Ayub''' sempre faz aos seus candidatos à vagas de emprego e não importa o quanto tenham de experiência em '''Engenharia de Redes''', todos sempre travam nesse momento. Todos estão sempre prontos e preparados para resolver os problemas mais cabeludos em '''BGP''', '''OSPF''', '''MPLS''', etc mas travam com essa simples pergunta. Para contextualizar e visualizarmos melhor vamos nos atentar à imagem abaixo e uma explicação simplificada de como funciona:
[[Arquivo:Dns hierarquia.png|esquerda|commoldura]]
Tudo começa com um usuário sentado confortavelmente e querendo acessar um conteúdo disponível na Internet. Ele digita em seu navegador preferido a URL: '''<nowiki>https://wiki.brasilpeeringforum.org</nowiki>''',

'''<big>1)</big>''' <big>O</big> <big>navegador irá requisitar do '''DNS Recursivo''' utilizado pelo usuário, o '''endereço IP''' que responde pelo nome '''wiki.'''</big>'''brasilpeeringforum.org'''<big>. Isso porque todos os acessos se dão na Internet através do '''endereço''' '''IP''' e não através do '''nome'''. Imaginem se tivéssemos que decorar os endereços IPs de todos os sites e serviços que quiséssemos acessar na Internet?</big>

<big>'''2)''' Nosso DNS Recursivo checa se a informação consta em seu cache.</big> Se a informação existir ela é devolvida ao navegador do usuário e aí este consegue acessar o site.

'''3)''' Do contrário o DNS Recursivo pergunta ao '''Root Server''' quem é o '''TLD (Top Level Domain)''' responsável para atender a requisição.

'''4)''' O '''Root Server''' informa ao DNS Recursivo o endereço do '''TLD responsável'''. No Brasil o '''TLD''' responsável pelo '''.br''' seria o '''Registro.br'''.

'''5)''' O DNS Recursivo pergunta ao '''TLD''' sobre '''wiki.brasilpeeringforum.org''' e este responde com os endereços IP dos '''DNS Autoritativos''' responsáveis pelo domínio '''brasilpeeringforum.org.'''

'''6)''' O DNS Recursivo pergunta aos '''DNS Autoritativos''' pelo '''wiki.brasilpeeringforum.org''' e este responde com o '''endereço IP'''.

'''7)''' Por último o DNS Recursivo devolve a informação para o navegador do usuário.

Como que se dá a comunicação entre os '''DNS(s) Recursivos, Root Servers, TLDs''' e '''Autoritativos'''? Como que o navegador do usuário, após receber o IP do site, consegue chegar no servidor que tem o conteúdo? Isso só é possível devido ao protocolo chamado '''BGP (Border Gateway Protocol)''', todos os caminhos que conhecemos como rotas de destino, são anunciadas por milhares de participantes na '''Internet''' conhecidos como '''AS (Autonomous System)''', esses participantes se interligam para disponibilizar conteúdos e acessos pelo mundo aos milhares de usuários. É uma imensa rede colaborativa formada por Empresas, Universidades, Governos e todos que queiram se interconectar. Percebam que sem o '''BGP''', que serve de caminho para chegarmos nos conteúdos e sem o '''DNS (Domain Name System)''' para traduzir o nome para o endereço IP, a '''Internet''' não funcionaria e por isso precisamos cuidar muito bem desses dois serviços.
 
Mas não acaba por aí. O '''DNS Recursivo''' tem um papel muito importante para o Provedor de Internet e que envolve segurança, qualidade de acesso à Internet e a disponibilidade do serviço entregue ao cliente. Quando bem configurado acelera as consultas dos acessos graças ao seu cache interno, mas para que isso seja percebido pelo assinante, é necessário que esteja o mais próximo possível do seu cliente.
 
== Um erro que destrói a qualidade do nosso serviço ==
Um erro muito comum que muitas operadoras cometem é utilizar DNS Recursivo externo, como o '''8.8.8.8''', '''1.1.1.1''' e outros, para seus clientes. Quanto mais próximo dos seus clientes, mais qualidade de serviço estará entregando a eles. Conteúdos serão entregues mais rapidamente pois serão resolvidos e armazenados em caches locais e não consultados remotamente na Internet. Para falar mais sobre isso, te convido leitor desse documento, que assista essa palestra do '''Thiago Ayub''' no '''GTER 51/GTS 37''' (2022) '''8.888 MOTIVOS PARA NÃO USAR DNS RECURSIVO EXTERNO EM SEU AS''': https://www.youtube.com/watch?v=Rsvpu5uF2Io

== Objetivo ==
O objetivo desta documentação não é te ensinar tudo sobre '''DNS''', '''BGP''', '''OSPF''' e nem tão pouco sobre GNU/Linux e sim te mostrar um exemplo de servidor DNS Recursivo implementado pensando em segurança, qualidade e resiliência. Usaremos em todas as nossas documentações o [https://www.debian.org/ Debian GNU/Linux], por ser uma distribuição que considero uma obra de arte criada por uma enorme comunidade séria, com vasta experiência de anos, qualidade no empacotamento dos programas, estável e com uma equipe de segurança excelente e ativa. Caso você leitor, utilize alguma outra distribuição GNU/Linux, todo conteúdo apresentado aqui pode ser aplicado em outras distros, desde que respeitando as particularidades de cada uma.

Aqui construiremos um sistema do tipo '''Anycast''', ou seja, terás o serviço rodando em diversas localidades da sua Rede utilizando o mesmo endereçamento IP e que atenderá seu cliente mais próximo. Em caso de falhas, seus clientes automaticamente e de forma transparente continuarão consultando o DNS mais próximo deles. Para que ele funcione dessa forma você precisará ter uma '''Rede OSPF''' implementada no seu Provedor Internet ou algum outro protocolo como por exemplo o '''ISIS,''' mas esse documento não irá abordar o '''ISIS'''. Também utilizaremos o '''Hyperlocal''' como recurso adicional para gerar algumas proteções de segurança e velocidade na resposta relacionada aos servidores de DNS Raiz da Internet.

== Diagrama ==
Para exemplificar nosso servidor de DNS Recursivo, usaremos como base das explicações um diagrama demonstrando o uso do DNS Recursivo em uma Rede fictícia. Adotaremos IPs privados e reservados para demonstrar todo o ambiente do Provedor de Internet.
[[Arquivo:Diagrama dns recursiv2.png|alt=|esquerda|miniaturadaimagem|695x695px]]
Nesse diagrama podemos observar alguns detalhes técnicos como por exemplo: existem '''3 servidores de DNS Recursivo''' posicionados em locais diferentes, que poderiam estar em bairros diferentes e até em cidades diferentes. Em cada servidor teremos '''2 loopbacks''' com os IPs:

'''10.10.10.10/32 - fc00::10:10:10:10/128'''

'''10.10.9.9/32 - fc00::10:10:9:9/128'''

Esses IPs serão entregues pelos concentradores '''PPPoE''' ou '''IPoE''' ('''BNG''') para seus clientes como '''DNS primário''' e '''secundário'''. Podemos usar IPs privados como DNS primário e secundário em um ambiente real? Sim podemos, desde que não sejam IPs que possam ter problemas com as redes privadas dos clientes. Ex.: rede do cliente usando '''192.168.0.0/24'''. Se entregarmos o DNS sendo '''192.168.0.10''' e '''192.168.0.20''' teremos problemas e o cliente ficará sem Internet, porque '''192.168.0.10''' e '''192.168.0.20''' fazem parte da rede '''192.168.0.0/24'''.

Agora entregando '''10.10.10.10,''' '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9''' não teríamos problemas com a rede '''192.168.0.0/24'''.

'''Motivos para usarmos IPs privados:'''
* O principal motivo está relacionado com a segurança, uma vez que sendo um IP privado, não pode sofrer ataques DDoS direcionados diretamente para ele, vindos da Internet.
* Nem mesmo o cliente da sua rede conhece os '''IPs públicos''' utilizados para recursividade na Internet.
* Memorizar os IPs '''10.10.10.10''' e '''10.10.9.9''' é tão fácil quanto memorizar o '''8.8.8.8''' e o '''1.1.1.1'''. Mais fácil para o seu técnico guardar essa informação e utilizar onde for necessário.
Cada servidor DNS Recursivo possui um '''IPv4 público''', aqui representado por '''198.18.x.x/27''' e um '''IPv6 global''' representado por um IP dentro do prefixo '''2001:db8::/32'''. Cada servidor precisa ter os seus próprios IPs e são através destes IPs que as consultas de DNS serão realizadas na Internet.

Nessa topologia usando '''Anycast''', o cliente será sempre atendido pelo '''DNS Recursivo''' mais próximo, desde que os pesos no '''OSPF''' estejam ajustados corretamente.
 
== Dados do servidor ==
Podemos utilizar um sistema virtualizado ou não. Sistemas virtualizados são bem vindos pois são mais simples quando precisamos fazer backups, levantar outros sistemas sem complicações e se precisarmos restaurar rapidamente algum sistema que ficou indisponível por algum motivo. A configuração abaixo tem capacidade para atender algo em torno a '''50.000 assinantes ou mais'''. O DNS Recursivo é um serviço que pode ser utilizado até mesmo em um '''Raspberry Pi''' e atender operações pequenas, nesse caso com o intuito de economizar energia e espaço. Nosso foco aqui é montar uma rede de '''DNS Recursivo Anycast com HyperLocal'''. Como comentei acima o servidor deve ficar o mais próximo dos clientes para termos a '''menor latência possível''' e '''sempre menor que 5ms''' entre o cliente e o servidor.
{| class="wikitable"
|+
!CPU
!Memória
!Disco
!Sistema
|-
|2.4Ghz 4 cores
|16G DDR4
|30G
|Debian 12 amd64 (Bookworm)
|}

== Softwares utilizados ==
* Debian 12 amd64 (Bookworm) instalação mínima.

* [https://frrouting.org/ FRRouting].
* Unbound.
* IRQBalance.
* Chrony (NTP/NTS).
* Shell script em bash.

== Funcionalidades que teremos ==
* Sistema em Anycast.
* Hyperlocal.
* Controle de acesso por <abbr>ACL</abbr>.
* RPZ (Response Policy Zone).
* Bloqueio de consultas do tipo ANY.
* QNAME minimization habilitado. (habilitado por default no Unbound)
* Recursividade em IPv4 e IPv6.
* DNSSEC habilitado.
* <abbr>DoH (DNS</abbr> over HTTPS) habilitado.

== Monitoramento ==
O monitoramento é algo bem específico e não é o foco deste documento mas é extremamente importante que você monitore seus servidores de DNS por alguma ferramenta como o Zabbix. Aqui mostrarei apenas como enviar as informações para o Zabbix. Algumas coisas que você deveria monitorar nos servidores de DNS Recursivo:
* Serviço do unbound parou.
* Perda de pacotes.
* Latência alta de pacotes.
* Lentidão na resolução de queries.
* CPU alta.
* Load alto.
* Memória com uso alto.
* Disco com pouco espaço.
* Queda brusca nas queries.
* A recursividade parou de funcionar.
* A recursividade voltou a funcionar.
Este abaixo é um exemplo de monitoramento de um sistema de DNS Recursivo que atende 50.000 assinantes:
[[Arquivo:Grafana dns.png|nenhum|commoldura]]

== Configurando a Rede ==
Nossa documentação será baseada no diagrama apresentado acima e por isso configuraremos apenas um dos três servidores, porque os outros serão configurados da mesma forma, só que com dados diferentes. Para tanto assumirei que já temos um sistema Debian instalado com o mínimo de pacotes e somente com sshd, para que possamos acessar remotamente mais tarde. '''Não instale um ambiente gráfico no servidor''', você não deve querer fazer isso por diversos motivos e os principais: primeiro porque não é um Desktop e segundo porque o ambiente gráfico devoraria toda a memória com recursos que não seriam úteis aqui.

Em '''/etc/network/interfaces''' deixaremos assim:
# 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

auto lo:1
iface lo:1 inet static
address 10.10.9.9/32

auto lo:2
iface lo:2 inet6 static
address fc00::10:10:10:10/128

auto lo:3
iface lo:3 inet6 static
address fc00::10:10:9:9/128

# The primary network interface
auto ens18
iface ens18 inet static
address 198.18.1.10/27
gateway 198.18.1.1

iface ens18 inet6 static
address 2001:db8::faca:198:18:1:10/64
gateway 2001:db8::faca:198:18:1:1

# The secondary network interface
auto ens18:0
iface ens18:0 inet static
address 172.16.0.6/30
Nesse cenário temos as duas '''loopbacks''' com os IPs '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10''' e '''fc00::10:10:9:9''' que serão anunciados via OSPF para a rede e serem entregues aos clientes via BNG. Os IPs '''198.18.1.10''' e '''2001:db8::faca:198:18:1:10''' serão usados para fazerem a recursividade na Internet tanto em IPv4 quanto em IPv6. Esses IPs não devem ser divulgados para clientes; os IPs públicos são dedicados apenas para essa finalidade.

== Configuração dos repositórios Debian ==
Deixe o arquivo '''/etc/apt/sources.list''' conforme abaixo:
deb <nowiki>http://security.debian.org/debian-security</nowiki> bookworm-security main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-updates main contrib non-free non-free-firmware
deb <nowiki>http://deb.debian.org/debian</nowiki> bookworm-backports main contrib non-free non-free-firmware
Após a configuração vamos instalar alguns pacotes necessários e outros úteis:
# apt update && apt full-upgrade
# apt install net-tools nftables htop iotop sipcalc tcpdump curl gnupg rsync wget host dnsutils mtr-tiny bmon sudo tmux whois ethtool dnstop

== Fazendo algum tuning no sistema ==
Em '''/etc/sysctl.conf''' adicionamos no final do arquivo essas instruções:
net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_rmem = 4096 87380 2147483647
net.ipv4.tcp_wmem = 4096 65536 2147483647
net.netfilter.nf_conntrack_buckets = 512000
net.netfilter.nf_conntrack_max = 4096000
vm.swappiness=10
Estamos fazendo algumas melhorias de memória, algumas relacionadas a '''conntrack''' porque se for usar um filtro de pacotes stateful, como o '''Netfilter/IPTables''' ou '''Netfilter/NFTables''', o valor default da tabela é pequeno e dependendo da situação, se estourar essa tabela, as consultas de DNS terão problemas também. O DNS Recursivo não deve ficar aberto para qualquer um na Internet, ele deve ser liberado apenas para seus clientes. Podemos fazer através das ACLs do Unbound e pelo filtro de pacotes. O último parâmetro diz respeito ao uso de swap, por padrão o Debian permite o uso de swap após 40% do uso da memória, nesse caso estamos dizendo para o sistema usar o swap com 90% de uso da memória.

Precisamos adicionar o módulo '''nf_conntrack''' em '''/etc/modules''' para que seja carregado em tempo de boot, senão os parâmetros de '''conntrack''' que colocamos em '''/etc/sysctl.conf''' não serão carregados.
# echo nf_conntrack >> /etc/modules
# modprobe nf_conntrack
# sysctl -p

== Instalando o FRRouting ==
O FRRouting é o programa que usaremos para fazer os anúncios das nossas loopbacks via OSPF. Nesse documento usaremos a versão 10.x e para isso precisaremos configurar o repositório oficial do FRRouting e instalar os pacotes:
# curl -s <nowiki>https://deb.frrouting.org/frr/keys.gpg</nowiki> | tee /usr/share/keyrings/frrouting.gpg > /dev/null
# echo "deb [signed-by=/usr/share/keyrings/frrouting.gpg] <nowiki>https://deb.frrouting.org/frr</nowiki> bookworm frr-10" > /etc/apt/sources.list.d/frr.list
# apt update
# apt install frr frr-doc frr-pythontools
Aconselho depois de instalar os pacotes, marcá-los para não atualizar juntamente com os demais pacotes, isso é para evitar de ocorrer alguma atualização no FRRouting, que torne o serviço instável por algum motivo. Não que isso vá ocorrer, mas é melhor fazer essa atualização quando realmente for necessário.
# apt-mark hold frr frr-doc frr-pythontools
Após esse comando acima, o sistema manterá a instalação original do pacote intacta. Para desbloquear basta executar o comando abaixo:
# apt-mark unhold frr frr-doc frr-pythontools

== Removendo o APPARMOR ==
O '''APPARMOR''' às vezes causa mais problemas que solução e se não for fazer uma completa configuração nele, é melhor desabilitá-lo. Para fazer isso efetivamente, o procedimento é esse abaixo:
# mkdir -p /etc/default/grub.d
# echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"' | tee /etc/default/grub.d/apparmor.cfg
# update-grub
# reboot

== Instalando o Unbound ==
Nesse momento ainda não iremos configurar o Unbound, apenas instalar o pacote e acertar o ambiente. Vamos instalar o unbound do backports porque este já possui suporte ao DoH que veremos mais à frente.
# apt install unbound dns-root-data
# mkdir -p /var/log/unbound
# touch /var/log/unbound/unbound.log
# chown -R unbound:unbound /var/log/unbound/
# systemctl restart unbound
Configurando o logrotate:
cat << EOF > /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
rotate 5
weekly
postrotate
unbound-control log_reopen
endscript
}
EOF
Reiniciando o serviço:
# systemctl restart logrotate.service

== Preparando o monitoramento do seu DNS Recursivo ==
O monitoramento do seu DNS Recursivo é muito importante e para isso vamos usar um '''template para Zabbix''', que modifiquei juntamente com o seu shell script e que enviará os dados para o seu Zabbix server via '''zabbix-sender'''. O projeto original está aqui '''https://github.com/jeftedelima/Unbound-DNS<nowiki/>.''' O xml alterado está aqui '''https://github.com/gondimcodes/template_zabbix_dns_unbound'''. Embora seja antigo é perfeitamente importável no Zabbix 6.0, por exemplo.

'''<nowiki/>'''

Teremos um shell script que você precisará colocar no seu '''/etc/crontab'''. No exemplo abaixo assumi que o shell script está em '''/root/scripts'''. De 5 em 5 minutos os dados serão enviados para o seu Zabbix server.
*/5 * * * * root /root/scripts/unboundSend.sh '''IP_zabbix_server''' '''nome_do_host''' 1> /dev/null
Na linha acima, troque o '''IP_zabbix_server''' pelo '''IP do seu servidor Zabbix''' e o '''nome_do_host''' pelo '''hostname''' '''do seu DNS Recursivo'''. Você precisará instalar o pacote '''zabbix-sender''' no seu DNS Recursivo pois ele será usado para enviar os dados para o Zabbix server.

Abaixo o '''unboundSend.sh''' também alterado com inclusão de mais dados:
#!/bin/bash
# @Jefte de Lima Ferreira
# jeftedelima at gmail dot com
# CRON Example
# Contributor: Marcelo Gondim - gondim at gmail dot com
# */5 **** root sh /home/dir/unboundSend.sh 192.168.10.1 Unbound 1> /dev/null

if [ -z ${1} ] || [ -z ${2} ] ; then
echo "You need to specify the IP address of zabbix server and hostname of your DNS Unbound on zabbix"
echo "Usage example: ./unboundSend.sh 192.168.10.1 UnboundServer"
exit 1
fi

# ZABBIX_SERVER IP
IP_ZABBIX=$1
# NAME Unbound on Zabbix
NAME_HOST=$2
DIR_TEMP=/var/tmp/
FILE="${DIR_TEMP}dump_unbound_control_stats.txt"
unbound-control stats > ${FILE}

TOTAL_NUM_QUERIES=$(cat ${FILE} | grep -w 'total.num.queries' | cut -d '=' -f2)
TOTAL_NUM_CACHEHITS=$(cat ${FILE} | grep -w 'total.num.cachehits' | cut -d '=' -f2)
TOTAL_NUM_CACHEMISS=$(cat ${FILE} | grep -w 'total.num.cachemiss' | cut -d '=' -f2)
TOTAL_NUM_PREFETCH=$(cat ${FILE} | grep -w 'total.num.prefetch' | cut -d '=' -f2)
TOTAL_NUM_RECURSIVEREPLIES=$(cat ${FILE} | grep -w 'total.num.recursivereplies' | cut -d '=' -f2)

TOTAL_REQ_MAX=$(cat ${FILE} | grep -w 'total.requestlist.max' | cut -d '=' -f2)
TOTAL_REQ_AVG=$(cat ${FILE} | grep -w 'total.requestlist.avg' | cut -d '=' -f2)
TOTAL_REQ_OVERWRITTEN=$(cat ${FILE} | grep -w 'total.requestlist.overwritten' | cut -d '=' -f2)
TOTAL_REQ_EXCEEDED=$(cat ${FILE} | grep -w 'total.requestlist.exceeded' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_ALL=$(cat ${FILE} | grep -w 'total.requestlist.current.all' | cut -d '=' -f2)
TOTAL_REQ_CURRENT_USER=$(cat ${FILE} | grep -w 'total.requestlist.current.user' | cut -d '=' -f2)

TOTAL_TCPUSAGE=$(cat ${FILE} | grep -w 'total.tcpusage' | cut -d '=' -f2)

NUM_QUERY_TYPE_A=$(cat ${FILE} | grep -w 'num.query.type.A' | cut -d '=' -f2)
NUM_QUERY_TYPE_NS=$(cat ${FILE} | grep -w 'num.query.type.NS' | cut -d '=' -f2)
NUM_QUERY_TYPE_MX=$(cat ${FILE} | grep -w 'num.query.type.MX' | cut -d '=' -f2)
NUM_QUERY_TYPE_TXT=$(cat ${FILE} | grep -w 'num.query.type.TXT' | cut -d '=' -f2)
NUM_QUERY_TYPE_PTR=$(cat ${FILE} | grep -w 'num.query.type.PTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_AAAA=$(cat ${FILE} | grep -w 'num.query.type.AAAA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SRV=$(cat ${FILE} | grep -w 'num.query.type.SRV' | cut -d '=' -f2)
NUM_QUERY_TYPE_SOA=$(cat ${FILE} | grep -w 'num.query.type.SOA' | cut -d '=' -f2)
NUM_QUERY_TYPE_HTTPS=$(cat ${FILE} | grep -w 'num.query.type.HTTPS' | cut -d '=' -f2)
NUM_QUERY_TYPE_TYPE0=$(cat ${FILE} | grep -w 'num.query.type.TYPE0' | cut -d '=' -f2)
NUM_QUERY_TYPE_CNAME=$(cat ${FILE} | grep -w 'num.query.type.CNAME' | cut -d '=' -f2)
NUM_QUERY_TYPE_WKS=$(cat ${FILE} | grep -w 'num.query.type.WKS' | cut -d '=' -f2)
NUM_QUERY_TYPE_HINFO=$(cat ${FILE} | grep -w 'num.query.type.HINFO' | cut -d '=' -f2)
NUM_QUERY_TYPE_X25=$(cat ${FILE} | grep -w 'num.query.type.X25' | cut -d '=' -f2)
NUM_QUERY_TYPE_NAPTR=$(cat ${FILE} | grep -w 'num.query.type.NAPTR' | cut -d '=' -f2)
NUM_QUERY_TYPE_DS=$(cat ${FILE} | grep -w 'num.query.type.DS' | cut -d '=' -f2)
NUM_QUERY_TYPE_DNSKEY=$(cat ${FILE} | grep -w 'num.query.type.DNSKEY' | cut -d '=' -f2)
NUM_QUERY_TYPE_TLSA=$(cat ${FILE} | grep -w 'num.query.type.TLSA' | cut -d '=' -f2)
NUM_QUERY_TYPE_SVCB=$(cat ${FILE} | grep -w 'num.query.type.SVCB' | cut -d '=' -f2)
NUM_QUERY_TYPE_SPF=$(cat ${FILE} | grep -w 'num.query.type.SPF' | cut -d '=' -f2)
NUM_QUERY_TYPE_ANY=$(cat ${FILE} | grep -w 'num.query.type.ANY' | cut -d '=' -f2)
NUM_QUERY_TYPE_OTHER=$(cat ${FILE} | grep -w 'num.query.type.other' | cut -d '=' -f2)

NUM_ANSWER_RCODE_NOERROR=$(cat ${FILE} | grep -w 'num.answer.rcode.NOERROR' | cut -d '=' -f2)
NUM_ANSWER_RCODE_NXDOMAIN=$(cat ${FILE} | grep -w 'num.answer.rcode.NXDOMAIN' | cut -d '=' -f2)
NUM_ANSWER_RCODE_SERVFAIL=$(cat ${FILE} | grep -w 'num.answer.rcode.SERVFAIL' | cut -d '=' -f2)
NUM_ANSWER_RCODE_REFUSED=$(cat ${FILE} | grep -w 'num.answer.rcode.REFUSED' | cut -d '=' -f2)
NUM_ANSWER_RCODE_nodata=$(cat ${FILE} | grep -w 'num.answer.rcode.nodata' | cut -d '=' -f2)
NUM_ANSWER_secure=$(cat ${FILE} | grep -w 'num.answer.secure' | cut -d '=' -f2)

# Sending info to zabbix_server, if variables is not empty!
[ -z ${TOTAL_NUM_QUERIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.queries -o $((TOTAL_NUM_QUERIES/300))
[ -z ${TOTAL_NUM_CACHEHITS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachehits -o $((TOTAL_NUM_CACHEHITS/300))
[ -z ${TOTAL_NUM_CACHEMISS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.cachemiss -o $((TOTAL_NUM_CACHEMISS/300))
[ -z ${TOTAL_NUM_PREFETCH} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.prefetch -o $((TOTAL_NUM_PREFETCH/300))
[ -z ${TOTAL_NUM_RECURSIVEREPLIES} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.num.recursivereplies -o $((TOTAL_NUM_RECURSIVEREPLIES/300))

[ -z ${TOTAL_REQ_MAX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.max -o $((TOTAL_REQ_MAX/300))
[ -z ${TOTAL_REQ_AVG} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.avg -o $((TOTAL_REQ_AVG/300))
[ -z ${TOTAL_REQ_OVERWRITTEN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.overwritten -o $((TOTAL_REQ_OVERWRITTEN/300))
[ -z ${TOTAL_REQ_EXCEEDED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.exceeded -o $((TOTAL_REQ_EXCEEDED/300))
[ -z ${TOTAL_REQ_CURRENT_ALL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.all -o $((TOTAL_REQ_CURRENT_ALL/300))
[ -z ${TOTAL_REQ_CURRENT_USER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.requestlist.current.user -o $((TOTAL_REQ_CURRENT_USER/300))

[ -z ${TOTAL_TCPUSAGE} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k total.tcpusage -o $((TOTAL_TCPUSAGE/300))

[ -z ${NUM_QUERY_TYPE_A} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.a -o $((NUM_QUERY_TYPE_A/300))
[ -z ${NUM_QUERY_TYPE_NS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ns -o $((NUM_QUERY_TYPE_NS/300))
[ -z ${NUM_QUERY_TYPE_MX} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.mx -o $((NUM_QUERY_TYPE_MX/300))
[ -z ${NUM_QUERY_TYPE_TXT} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.txt -o $((NUM_QUERY_TYPE_TXT/300))
[ -z ${NUM_QUERY_TYPE_PTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ptr -o $((NUM_QUERY_TYPE_PTR/300))
[ -z ${NUM_QUERY_TYPE_AAAA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.aaaa -o $((NUM_QUERY_TYPE_AAAA/300))
[ -z ${NUM_QUERY_TYPE_SRV} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.srv -o $((NUM_QUERY_TYPE_SRV/300))
[ -z ${NUM_QUERY_TYPE_SOA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.soa -o $((NUM_QUERY_TYPE_SOA/300))
[ -z ${NUM_QUERY_TYPE_HTTPS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.https -o $((NUM_QUERY_TYPE_HTTPS/300))
[ -z ${NUM_QUERY_TYPE_TYPE0} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.type0 -o $((NUM_QUERY_TYPE_TYPE0/300))
[ -z ${NUM_QUERY_TYPE_CNAME} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.cname -o $((NUM_QUERY_TYPE_CNAME/300))
[ -z ${NUM_QUERY_TYPE_WKS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.wks -o $((NUM_QUERY_TYPE_WKS/300))
[ -z ${NUM_QUERY_TYPE_HINFO} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.hinfo -o $((NUM_QUERY_TYPE_HINFO/300))
[ -z ${NUM_QUERY_TYPE_X25} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.X25 -o $((NUM_QUERY_TYPE_X25/300))
[ -z ${NUM_QUERY_TYPE_NAPTR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.naptr -o $((NUM_QUERY_TYPE_NAPTR/300))
[ -z ${NUM_QUERY_TYPE_DS} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.ds -o $((NUM_QUERY_TYPE_DS/300))
[ -z ${NUM_QUERY_TYPE_DNSKEY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.dnskey -o $((NUM_QUERY_TYPE_DNSKEY/300))
[ -z ${NUM_QUERY_TYPE_TLSA} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.tlsa -o $((NUM_QUERY_TYPE_TLSA/300))
[ -z ${NUM_QUERY_TYPE_SVCB} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.svcb -o $((NUM_QUERY_TYPE_SVCB/300))
[ -z ${NUM_QUERY_TYPE_SPF} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.spf -o $((NUM_QUERY_TYPE_SPF/300))
[ -z ${NUM_QUERY_TYPE_ANY} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.any -o $((NUM_QUERY_TYPE_ANY/300))
[ -z ${NUM_QUERY_TYPE_OTHER} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.query.other -o $((NUM_QUERY_TYPE_OTHER/300))

[ -z ${NUM_ANSWER_RCODE_NOERROR} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NOERROR -o $((NUM_ANSWER_RCODE_NOERROR/300))
[ -z ${NUM_ANSWER_RCODE_NXDOMAIN} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.NXDOMAIN -o $((NUM_ANSWER_RCODE_NXDOMAIN/300))
[ -z ${NUM_ANSWER_RCODE_SERVFAIL} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.SERVFAIL -o $((NUM_ANSWER_RCODE_SERVFAIL/300))
[ -z ${NUM_ANSWER_RCODE_REFUSED} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.REFUSED -o $((NUM_ANSWER_RCODE_REFUSED/300))
[ -z ${NUM_ANSWER_RCODE_nodata} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.rcode.nodata -o $((NUM_ANSWER_RCODE_nodata/300))
[ -z ${NUM_ANSWER_secure} ] || zabbix_sender -z ${IP_ZABBIX} -s ${NAME_HOST} -k num.answer.secure -o $((NUM_ANSWER_secure/300))
No Zabbix será registrado dados como esses abaixo e posteriormente pode ser montado um Grafana com eles:
[[Arquivo:Zabbix dns01.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns02.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns03.png|nenhum|commoldura]]
[[Arquivo:Zabbix dns04.png|nenhum|commoldura]]

== Balanceando o processamento e mantendo a hora certa ==
Vamos instalar 2 programas agora, o IRQBalance e o Chrony. O primeiro para balancear a carga entre os cores e o segundo para manter a data e hora certas no sistema:
# apt install irqbalance
# systemctl enable irqbalance
# apt install chrony
Após a instalação do Chrony edite o arquivo /etc/chrony/chrony.conf, comente e a linha abaixo e adicione seus servidores NTP. Caso não tenha servidores NTP, estou colocando os do NIC.br aqui.
#pool 2.debian.pool.ntp.org iburst
server a.st1.ntp.br iburst nts
server b.st1.ntp.br iburst nts
server c.st1.ntp.br iburst nts
server d.st1.ntp.br iburst nts

# systemctl restart chronyd.service
Cheque com o '''chronyc''' se os servidores estão OK:
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
a.st1.ntp.br 10 5 155m -0.027 0.030 -71us 51us
b.st1.ntp.br 11 7 344m +0.068 0.079 +23ms 382us
c.st1.ntp.br 6 3 344m +0.026 0.037 -124us 92us
200.20.186.76 9 3 138m -0.022 0.031 +172us 42us

# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* a.st1.ntp.br 1 10 377 588 +487us[ +397us] +/- 12ms
^- b.st1.ntp.br 2 10 377 830 +23ms[ +23ms] +/- 49ms
^+ c.st1.ntp.br 2 10 21 1038 -147us[ -242us] +/- 17ms
^+ 200.20.186.76 1 10 377 1032 +381us[ +285us] +/- 15ms

== Configurando o FRRouting ==
Nesse ponto iremos configurar o '''FRRouting''' para enviar os IPs das '''loopbacks''' e o '''/30''' para o nosso PE do diagrama. Em '''/etc/frr/daemons''' habilite o parâmetro conforme abaixo:
ospfd=yes
Edite o arquivo '''/etc/frr/frr.conf''' e deixe com o conteúdo abaixo, para ficar conforme nosso diagrama do projeto. Apenas troque '''<SENHA>''' por uma senha para fechar o OSPF com mais segurança. Essa senha deve ser usada dos dois lados.
frr version 10.2.1
frr defaults traditional
hostname dns-recursivo-01
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens18
ip ospf area 0.0.0.0
ip ospf message-digest-key 5 md5 <SENHA>
ip ospf network point-to-point
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 network point-to-point
exit
!
interface lo
description LOOPBACKS
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 172.16.0.6
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 172.16.0.6
exit
!

# systemctl restart frr.service
Cheque se está tudo OK com o OSPF e verifique no PE se está recebendo os prefixos anunciados.
# vtysh -c 'show ip ospf neighbor'

Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
172.16.0.5 1 Full/- 10m49s 35.310s 172.16.0.5 ens18:172.16.0.6 0 0 0

# vtysh -c 'show ipv6 ospf6 neighbor'

Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
172.16.0.5 1 00:00:30 Full/PointToPoint 25d22:53:47 ens18[PointToPoint]

# vtysh -c 'show ip ospf neighbor detail'

Neighbor 172.16.0.5, interface address 172.16.0.5
In the area 0.0.0.0 via interface ens18
Neighbor priority is 1, State is Full/-, 5 state changes
Most recent state change statistics:
Progressive change 21w3d15h ago
DR is 0.0.0.0, BDR is 0.0.0.0
Options 18 *|-|-|EA|-|-|E|-
Dead timer due in 34.685s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on

Graceful restart Helper info:
Graceful Restart HELPER Status : None

# vtysh -c 'show ipv6 ospf6 neighbor detail'
Neighbor 172.16.0.5%ens18
Area 0.0.0.0 via interface ens18 (ifindex 4)
His IfIndex: 60 Link-local address: fe80::469b:c1ff:fed6:43ee
State Full for a duration of 25d22:57:14
His choice of DR/BDR 0.0.0.0/0.0.0.0, Priority 1
DbDesc status: Master SeqNum: 0xb94b0000
Summary-List: 0 LSAs
Request-List: 0 LSAs
Retrans-List: 0 LSAs
0 Pending LSAs for DbDesc in Time 00:00:00 [thread off]
0 Pending LSAs for LSReq in Time 00:00:00 [thread off]
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header not present

== Configurando o Unbound ==
Abaixo a configuração que usaremos nos servidores atentando para o detalhe do '''num-threads''', esse deve ter o valor igual ao número de CPUs do servidor.

Também os IPs utilizados em '''outgoing-interface''' que serão diferentes em cada servidor, esses serão os IPs usados para '''recursividade'''. Consulte o manual do Unbound para obter mais informações sobre cada parâmetro listado na configuração.

O tuning no Unbound pode ser alterado conforme abaixo:
num-threads = nº CPUs
so-reuseport = yes
*-slabs = potência de 2 próximo ao num-threads
msg-cache-size = 1g (quantidade de memória pra usar de cache)
rrset-cache-size = 2 * msg-cache-size
outgoing-range = 8192
num-queries-per-thread = 4096
so-rcvbuf e so-sndbuf = 4m ou 8m para servidores com muita requisição
Agora vamos criar nosso arquivo de configuração base em '''/etc/unbound/unbound.conf.d/local.conf''':
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
serve-expired: yes
interface: 127.0.0.1
interface: 10.10.10.10
interface: 10.10.9.9
interface: 172.16.0.6
interface: fc00::10:10:10:10
interface: fc00::10:10:9:9
interface: ::1
interface-automatic: no
outgoing-interface: 198.18.1.10
outgoing-interface: 2001:db8::faca:198:18:1:10
outgoing-range: 8192
outgoing-num-tcp: 1024
incoming-num-tcp: 2048
so-rcvbuf: 4m
so-sndbuf: 4m
so-reuseport: yes
edns-buffer-size: 1232
msg-cache-size: 1g
msg-cache-slabs: 4
num-queries-per-thread: 4096
rrset-cache-size: 2g
rrset-cache-slabs: 4
infra-cache-slabs: 4
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
chroot: ""
username: "unbound"
directory: "/etc/unbound"
logfile: "/var/log/unbound/unbound.log"
use-syslog: no
log-time-ascii: yes
log-queries: no
pidfile: "/var/run/unbound.pid"
root-hints: "/usr/share/dns/root.hints"
hide-identity: yes
hide-version: yes
unwanted-reply-threshold: 10000000
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
module-config: "respip validator iterator"
val-clean-additional: yes
val-log-level: 1
key-cache-slabs: 4
deny-any: yes
cache-min-ttl: 60
key-cache-size: 128m
neg-cache-size: 64m
cache-max-ttl: 86400
infra-cache-numhosts: 100000
access-control: 198.18.0.0/22 allow
access-control: 2001:db8::/32 allow

rpz:
name: rpz.block.host.local.zone
zonefile: /etc/unbound/rpz.block.hosts.zone
rpz-action-override: nxdomain

python:

auth-zone:
name: "."
master: "b.root-servers.net"
master: "c.root-servers.net"
master: "d.root-servers.net"
master: "f.root-servers.net"
master: "g.root-servers.net"
master: "k.root-servers.net"
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"

auth-zone:
name: "arpa."
master: "lax.xfr.dns.icann.org"
master: "iad.xfr.dns.icann.org"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/arpa.zone"
No parâmetro '''interface''' colocamos os IPs que serão usados para consulta dos clientes como o '''10.10.10.10''', '''10.10.9.9, fc00::10:10:10:10 e fc00::10:10:9:9'''. Ali repare que coloquei também o IP privado '''172.16.0.6''', isso porque cada servidor terá o seu IP privado e este deve ser usado pelo seu sistema de monitoramento para checar cada servidor. No '''outgoing-interface''' teremos os IPs, tanto '''IPv4''' quanto '''IPv6''', para que seja feita a recursividade na Internet utilizando eles. Não tem '''IPv6''' ainda na sua rede? Dê uma olhada nesse artigo. Outro parâmetro importante é o '''access-control''' e é através dele que liberamos os prefixos IP para consultarem no nosso DNS Recursivo. No exemplo estou liberando todo o prefixo '''198.18.0.0/22''' e o prefixo '''2001:db8::/32'''. Além da ACL no Unbound, recomendo que crie um filtro de pacotes com iptables ou nftables protegendo seu sistema e liberando as portas '''53/UDP''', '''53/TCP,''' '''443/TCP e 853/TCP''' apenas para seus clientes. Falarei sobre a '''443/TCP e 853/TCP''' mais para frente nessa mesma documentação.

Agora criaremos o arquivo '''RPZ''' ('''Response Policy Zones'''). Esse arquivo contém os sites que serão bloqueados via '''<abbr>DNS</abbr> Recursivo'''. São aqueles sites que às vezes você recebe um Ofício da Justiça solicitando o bloqueio deles. Não entrarei no mérito da efetividade desses bloqueios, porque muitos de vocês sabem que tecnicamente, existem formas de se fazer um bypass através desses bloqueios. Contudo vamos deixar nosso ambiente preparado para esses bloqueios e por isso crie o arquivo '''/etc/unbound/rpz.block.hosts.zone''' com esse conteúdo de exemplo:
$TTL 2h
@ IN SOA localhost. root.localhost. (2 6h 1h 1w 2h)
IN NS localhost.
; RPZ manual block hosts
*.josedascoves.com CNAME .
josedascoves.com CNAME .
No exemplo acima estamos bloqueando qualquer consulta de DNS para '''josedascoves.com''' ou qualquer coisa '''.josedascoves.com'''.

Para testar podemos fazer assim do próprio servidor:
# host josedascoves.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

Host josedascoves.com not found: 3(NXDOMAIN)
Se a resposta for '''NXDOMAIN''' então está funcionando o bloqueio. Para incluir novos bloqueios basta adicionar os domínios, um abaixo do outro, conforme o exemplo que coloquei no arquivo RPZ.

== Acertando o resolv.conf ==
Vamos modificar nosso /etc/resolv.conf para utilizar DNS externo. Sim você deve estar se perguntando em qual situação isso seria utilizado. Primeiro entenda que o Unbound não irá utilizar o DNS externo para fazer as consultas na Internet e sim, qualquer teste que você faça do servidor precisará apontar para o Unbound usando os IPs '''127.0.0.1''' ou '''::1'''. Faremos isso pela seguinte situação: imagine que o daemon unbound morreu mas você ainda continua com conectividade na Internet. Você conseguiria acessar qualquer local na Internet através do IP mas não através do hostname porque não conseguiria resolver nomes, seu unbound estaria fora do ar. Imagine ainda que você gostaria que seu servidor te avisasse do problema via Telegram ou e-mail. Por isso estamos utilizando um DNS externo no '''/etc/resolv.conf''', apenas para essas situações. Se você não quiser utilizar desse recurso, pode usar o '''127.0.0.1''' e '''::1''' no lugar.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888

== Script de teste de recursividade ==
Estamos montando uma '''Rede de DNS Recursivo Anycast''', então é muito importante que você monitore essa rede para saber se algum node morreu e iniciar o troubleshooting, resolver o problema e levantar o sistema novamente. Tudo isso é importante mas o cliente não deve ficar esperando até você resolver o problema, seu sistema precisa ser inteligente o suficiente para se remover da Rede quando tiver um problema e se inserir novamente, quando o problema estiver sido solucionado. Se você montar uma Rede de DNS e um dos nodes apresentar algum problema, todos os clientes atendidos por aquele node migrarão automaticamente e transparentemente para outro '''DNS Recursivo Anycast''' mais próximo. Isso se chama '''disponibilidade'''.

O script '''/root/scripts/checa_dns.sh''' abaixo tem a função de fazer os testes de recursividade e checar se o daemon do unbound continua rodando. Se algo acontecer, ele para o anúncio do '''10.10.10.10''' e '''10.10.9.9''' e retorna eles quando tudo estiver resolvido.
# mkdir /root/scripts

#!/usr/bin/env bash
#Script para teste de DNS v2.1
#-----------------------------------------------------------------------
#Informe um domínio por linha:
dominios_testar=(
www.google.com
www.terra.com.br
www.uol.com.br
www.globo.com
www.facebook.com
www.youtube.com
www.twitch.com
www.discord.com
www.debian.org
www.redhat.com
)
corte_taxa_falha=100 #Porcentagem de falha para executar uma ação
#-----------------------------------------------------------------------
remove_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" != "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'no description' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'no ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME morreu!" | /usr/local/sbin/telegram-notify --error --text -
fi
}

adiciona_ospf() {
habilitado="`vtysh -c 'show run' | grep \"LOOPBACKS\"`"
if [ "$habilitado" == "" ]; then
vtysh -c 'conf t' -c 'interface lo' -c 'description LOOPBACKS' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ip ospf passive' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 area 0.0.0.0' -c 'end' -c 'wr'
vtysh -c 'conf t' -c 'interface lo' -c 'ipv6 ospf6 passive' -c 'end' -c 'wr'
echo "Servidor $HOSTNAME retornou do inferno!" | /usr/local/sbin/telegram-notify --success --text -
fi
}

systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
echo "Servidor $HOSTNAME morreu DNS mas tentando levantar!" | /usr/local/sbin/telegram-notify --error --text -
systemctl restart unbound
systemctl status unbound &> /dev/null;
if [ $? -ne 0 ]; then
remove_ospf
exit
fi
echo "Servidor $HOSTNAME servico DNS voltou mas tinha morrido!" | /usr/local/sbin/telegram-notify --success --text -
fi

qt_falhas=0
qt_total="${#dominios_testar[@]}"
echo "total_dominios: $qt_total"
for site in "${dominios_testar[@]}"
do
resolver="127.0.0.1"
echo -e " - dominio $site - $resolver - \c"
host $site $resolver &> /dev/null
if [ $? -ne 0 ]; then
((qt_falhas++))
echo -e "[Falhou]"
else
echo -e "[OK]"
fi
done

taxa_falha=$((qt_falhas*100/qt_total))
echo "Falhas $qt_falhas/$qt_total ($taxa_falha%)"

if [ "$taxa_falha" -ge "$corte_taxa_falha" ]; then
remove_ospf
exit
fi
adiciona_ospf
Se rodarmos o script manualmente veremos isto:
# /root/scripts/checa_dns.sh
total_dominios: 10
- dominio www.google.com - 127.0.0.1 - [OK]
- dominio www.terra.com.br - 127.0.0.1 - [OK]
- dominio www.uol.com.br - 127.0.0.1 - [OK]
- dominio www.globo.com - 127.0.0.1 - [OK]
- dominio www.facebook.com - 127.0.0.1 - [OK]
- dominio www.youtube.com - 127.0.0.1 - [OK]
- dominio www.twitch.com - 127.0.0.1 - [OK]
- dominio www.discord.com - 127.0.0.1 - [OK]
- dominio www.debian.org - 127.0.0.1 - [OK]
- dominio www.redhat.com - 127.0.0.1 - [OK]
Falhas 0/10 (0%)
Se acontecer 100% de falhas o script irá remover os anúncios do OSPF. Se o daemon do unbound morrer, ele tentará reiniciá-lo. Se tudo normalizar o script irá retornar os anúncios para o OSPF. Deixei comentado no script as partes que enviariam uma notificação para o Telegram. Existem diversas documentações sobre isso na Internet, eu mesmo tenho uma. Assim que eu publicar aqui, atualizo essa documentação e sinta-se à vontade de modificar como desejar.
# chmod 700 /root/scripts/checa_dns.sh
Adicione a linha abaixo em seu '''/etc/crontab''':
*/1 * * * * root /root/scripts/checa_dns.sh

== Habilitando o DoH (<abbr>DNS</abbr> over HTTPS) e DoT (DNS over TLS) - opcional ==
Para habilitar o '''DoH''' e o '''DoT''' no Unbound é bem simples. O recurso do '''DoH''' e '''DoT''' vem para trazer mais segurança e privacidade para o usuário. É um recurso muito pouco utilizado ainda mas que seu cliente pode vir a pedir algum dia.

Você precisará gerar certificados SSL legítimos e para isso você poderá usar o '''Let's Encrypt''' só que de uma forma não tão convencional.

Na sequência vamos instalar o Let's Encrypt para gerarmos nosso certificado SSL:
# apt install letsencrypt
Escolha um '''hostname''' para ser usado no nosso '''DoH''' e aponte ele no seu DNS Autoritativo para seus IPs 10.10.10.10 e 10.10.9.9. Aqui vamos usar o seguinte como exemplo: '''doh.brasilpeeringforum.org'''. Para gerarmos nosso certificado iremos usar o tipo '''DNS-01''', ele não necessita que tenhamos um servidor web rodando no servidor e nem tão pouco levanta um serviço na porta 80 para checar o hostname. Ele utiliza o DNS como validador e vai te solicitar que crie um registro '''CNAME''' no seu '''DNS Autoritativo''' para provar que você tem o controle sobre aquele hostname. Antes disso vamos instalar um programa em Python para podermos automatizar nossa renovação de certificado no futuro. Esse programa se encontra '''[https://github.com/joohoi/acme-dns-certbot-joohoi/raw/master/acme-dns-auth.py aqui]''' mas vou deixá-lo abaixo já modificado o interpretador.

Crie o arquivo '''/etc/letsencrypt/acme-dns-auth.py''' com o conteúdo abaixo:
#!/usr/bin/env python3
import json
import os
import requests
import sys

### EDIT THESE: Configuration values ###

# URL to acme-dns instance
ACMEDNS_URL = "<nowiki>https://auth.acme-dns.io</nowiki>"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False

### DO NOT EDIT BELOW THIS POINT ###
### HERE BE DRAGONS ###

DOMAIN = os.environ["CERTBOT_DOMAIN"]
if DOMAIN.startswith("*."):
DOMAIN = DOMAIN[2:]
VALIDATION_DOMAIN = "_acme-challenge."+DOMAIN
VALIDATION_TOKEN = os.environ["CERTBOT_VALIDATION"]

class AcmeDnsClient(object):
"""
Handles the communication with ACME-DNS API
"""

def __init__(self, acmedns_url):
self.acmedns_url = acmedns_url

def register_account(self, allowfrom):
"""Registers a new ACME-DNS account"""

if allowfrom:
# Include whitelisted networks to the registration call
reg_data = {"allowfrom": allowfrom}
res = requests.post(self.acmedns_url+"/register",
data=json.dumps(reg_data))
else:
res = requests.post(self.acmedns_url+"/register")
if res.status_code == 201:
# The request was successful
return res.json()
else:
# Encountered an error
msg = ("Encountered an error while trying to register a new acme-dns "
"account. HTTP status {}, Response body: {}")
print(msg.format(res.status_code, res.text))
sys.exit(1)

def update_txt_record(self, account, txt):
"""Updates the TXT challenge record to ACME-DNS subdomain."""
update = {"subdomain": account['subdomain'], "txt": txt}
headers = {"X-Api-User": account['username'],
"X-Api-Key": account['password'],
"Content-Type": "application/json"}
res = requests.post(self.acmedns_url+"/update",
headers=headers,
data=json.dumps(update))
if res.status_code == 200:
# Successful update
return
else:
msg = ("Encountered an error while trying to update TXT record in "
"acme-dns. \n"
"------- Request headers:\n{}\n"
"------- Request body:\n{}\n"
"------- Response HTTP status: {}\n"
"------- Response body: {}")
s_headers = json.dumps(headers, indent=2, sort_keys=True)
s_update = json.dumps(update, indent=2, sort_keys=True)
s_body = json.dumps(res.json(), indent=2, sort_keys=True)
print(msg.format(s_headers, s_update, res.status_code, s_body))
sys.exit(1)

class Storage(object):
def __init__(self, storagepath):
self.storagepath = storagepath
self._data = self.load()

def load(self):
"""Reads the storage content from the disk to a dict structure"""
data = dict()
filedata = ""
try:
with open(self.storagepath, 'r') as fh:
filedata = fh.read()
except IOError as e:
if os.path.isfile(self.storagepath):
# Only error out if file exists, but cannot be read
print("ERROR: Storage file exists but cannot be read")
sys.exit(1)
try:
data = json.loads(filedata)
except ValueError:
if len(filedata) > 0:
# Storage file is corrupted
print("ERROR: Storage JSON is corrupted")
sys.exit(1)
return data

def save(self):
"""Saves the storage content to disk"""
serialized = json.dumps(self._data)
try:
with os.fdopen(os.open(self.storagepath,
os.O_WRONLY | os.O_CREAT, 0o600), 'w') as fh:
fh.truncate()
fh.write(serialized)
except IOError as e:
print("ERROR: Could not write storage file.")
sys.exit(1)

def put(self, key, value):
"""Puts the configuration value to storage and sanitize it"""
# If wildcard domain, remove the wildcard part as this will use the
# same validation record name as the base domain
if key.startswith("*."):
key = key[2:]
self._data[key] = value

def fetch(self, key):
"""Gets configuration value from storage"""
try:
return self._data[key]
except KeyError:
return None

if __name__ == "__main__":
# Init
client = AcmeDnsClient(ACMEDNS_URL)
storage = Storage(STORAGE_PATH)

# Check if an account already exists in storage
account = storage.fetch(DOMAIN)
if FORCE_REGISTER or not account:
# Create and save the new account
account = client.register_account(ALLOW_FROM)
storage.put(DOMAIN, account)
storage.save()

# Display the notification for the user to update the main zone
msg = "Please add the following CNAME record to your main DNS zone:\n{}"
cname = "{} CNAME {}.".format(VALIDATION_DOMAIN, account["fulldomain"])
print(msg.format(cname))

# Update the TXT record in acme-dns instance
client.update_txt_record(account, VALIDATION_TOKEN)

# chmod +x /etc/letsencrypt/acme-dns-auth.py
Usaremos a seguinte instrução para criar nosso certificado:
# certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d doh.brasilpeeringforum.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for doh.brasilpeeringforum.org
Performing the following challenges:
dns-01 challenge for doh.brasilpeeringforum.org
Running manual-auth-hook command: /etc/letsencrypt/acme-dns-auth.py
Output from manual-auth-hook command acme-dns-auth.py:
Please add the following CNAME record to your main DNS zone:
_acme-challenge.doh.brasilpeeringforum.org CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.

Waiting for verification...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Nesse momento você cria o registro '''CNAME''' no seu DNS Autoritativo conforme ele solicitou: '''_acme-challenge.doh.brasilpeeringforum.org IN CNAME b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.''' e somente depois de criado e checado no DNS, você pressiona o '''Enter''' para continuar. Você pode checar dessa forma:
# host -t cname _acme-challenge.doh.brasilpeeringforum.org
_acme-challenge.doh.brasilpeeringforum.org is an alias for b555d682-7b50-45d9-a92f-3c3d187dd4e7.auth.acme-dns.io.
Para que nosso certificado seja automaticamente renovado colocaremos no '''/etc/crontab''' a seguinte linha abaixo:
00 00 1 * * root /usr/bin/certbot -q renew
Acima temos a instrução para renovação automática do certificado. Repare que você vai precisar também copiar esse certificado para seus outros servidores, escolha um servidor para manter o certificado sempre atualizado e crie um script que faça a mesma cópia remotamente para os outros servidores. O '''scp''' e o '''rsync''' são seus aliados nisso.

=== Configurando o Unbound ===
Em nosso '''/etc/unbound/unbound.conf.d/local.conf''', adicionaremos no bloco "'''server:'''" o seguinte:
interface: 10.10.10.10@443
interface: 10.10.9.9@443
interface: fc00::10:10:10:10@443
interface: fc00::10:10:9:9@443
interface: 10.10.10.10@853
interface: 10.10.9.9@853
interface: fc00::10:10:10:10@853
interface: fc00::10:10:9:9@853
tls-service-key: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/privkey.pem"
tls-service-pem: "/etc/letsencrypt/live/doh.brasilpeeringforum.org/fullchain.pem"
Para usar o recurso do '''DoH''' você precisará habilitar o recurso no seu navegador e informar a URL. Vou colocar o exemplo do '''Google Chrome''': Digite '''chrome://settings/security?search=dns''' no seu Chrome e ative '''Usar DNS seguro''', selecione '''Personalizado''' e adicione nossa URL:
[[Arquivo:Doh bpf2.png|nenhum|commoldura]]

== Finalizando ==
Aqui finalizamos nosso projeto para uma Rede de DNS(s) Recursivos Anycast com Hyperlocal. Esse projeto é escalável, seguro, resiliente e você entregará muito mais qualidade de Internet para o seu cliente. Pare de entregar o '''8.8.8.8''' para os seus clientes, você está contribuindo para uma Internet mais lenta, sem a qualidade que o seu cliente merece. Investi meu tempo, que é muito pouco, para deixar esse documento para a comunidade, para você melhorar o seu ISP, para dar um UP! nele, então vamos começar 2023 com o pé direito. O que acha?

Como prova de conceito, uma imagem abaixo onde temos uma Rede em produção de DNS(s) Recursivos Anycast e apontando exatamente o momento em que houve alguma situação que fez com que as queries de DNS, convergissem de um node para outro, de forma transparente e automática para o cliente. Podemos notar também que ao ser resolvido o problema, o tráfego retornou para o seu node correto:
[[Arquivo:Convergencia.png|nenhum|commoldura]]

== KINDNS (Stands for Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) ==
Achou que havia terminado? Agora que você tem a capacidade de montar uma '''Rede de DNS Recursivo''' com todas essas features acima, com todas as ferramentas que foram comentadas, o que acha de certificar o que fez?

Assim como o [https://www.manrs.org/ MANRS] veio para certificar nosso sistema de roteamento na Internet, agora temos o [https://kindns.org/ KINDNS] para certificar que nossos sistemas de DNS estão bem feitos e dentro dos padrões de segurança. Existem '''7 ações''' que podem ser certificadas para nossos DNS Recursivos e estão aqui em https://kindns.org/shared-private-resolvers/. Com essa nossa documentação, se bem aplicada, você pode se candidatar ao KINDNS e ter seu ASN listado aqui https://kindns.org/participants/

Obter e manter o '''MANRS''' e '''KINDNS''' demonstra seu compromisso com as Boas Práticas, contribui para termos uma '''Internet''' mais segura e te abre portas para novos negócios que possam exigir essas conformidades.

Autor: [[Usuário:Gondim|Marcelo Gondim]]
[[Categoria:Infraestrutura]]
__FORCARTDC__