Fundamentos do DNS e Preparação para Instalação no Oracle Linux 9
Este é o primeiro artigo de nossa série sobre implementação e configuração do DNS BIND no Oracle Linux 9. Nesta série, abordaremos desde os conceitos fundamentais até configurações avançadas, segurança e troubleshooting.
Introdução
O Sistema de Nomes de Domínio (DNS) é frequentemente descrito como a “agenda telefônica da Internet”. Embora essa analogia seja simplificada, ela captura a essência do que o DNS faz: traduzir nomes de domínio amigáveis (como example.com) em endereços IP numéricos (como 192.168.200.10 ou 2001:db8::1) que os computadores utilizam para se comunicar.
Sem o DNS, a Internet como conhecemos seria praticamente inutilizável, pois precisaríamos memorizar endereços IP para acessar qualquer site ou serviço. Além disso, o DNS desempenha funções críticas para a infraestrutura moderna, como balanceamento de carga, redundância e segurança.
Neste primeiro artigo da série, vamos explorar os fundamentos do DNS, sua importância, estrutura hierárquica, tipos de servidores e registros, além de preparar o ambiente para a instalação do BIND no Oracle Linux 9.
A Importância do DNS na Infraestrutura Moderna
O DNS vai muito além da simples tradução de nomes para endereços IP. Sua importância na infraestrutura moderna pode ser observada em diversos aspectos:
1. Escalabilidade e Flexibilidade
O DNS permite que serviços sejam movidos para diferentes servidores ou data centers sem que os usuários percebam, simplesmente atualizando os registros DNS. Isso proporciona flexibilidade operacional e facilita migrações e atualizações.
2. Balanceamento de Carga e Alta Disponibilidade
Através de técnicas como Round Robin DNS ou registros com TTL (Time To Live) baixos, o DNS pode distribuir o tráfego entre múltiplos servidores, melhorando o desempenho e a disponibilidade.
3. Segurança e Políticas
O DNS moderno incorpora extensões de segurança (DNSSEC) e pode ser usado para implementar políticas de segurança, como filtrar domínios maliciosos ou redirecionar tráfego para proxies de segurança.
4. Descoberta de Serviços
Registros SRV e outros tipos especializados permitem a descoberta automática de serviços em uma rede, facilitando a configuração de clientes e a integração de sistemas.
5. Geolocalização e CDN
Serviços de DNS avançados podem direcionar usuários para o servidor mais próximo geograficamente, otimizando a experiência do usuário e reduzindo latência.
A Hierarquia do DNS
O DNS é organizado em uma estrutura hierárquica em forma de árvore invertida, que permite a delegação de autoridade e a distribuição da carga de consultas. Vamos entender cada nível desta hierarquia:
1. Servidores Raiz (Root Servers)
No topo da hierarquia estão os servidores raiz, representados por um ponto “.” (que geralmente é omitido). Existem 13 conjuntos de servidores raiz (identificados de A a M), distribuídos globalmente e operados por diferentes organizações.
Os servidores raiz conhecem os servidores autoritativos para todos os domínios de primeiro nível (TLDs) e são o ponto de partida para consultas recursivas.
2. Domínios de Primeiro Nível (TLDs)
Logo abaixo dos servidores raiz estão os TLDs, que incluem:
- TLDs Genéricos (gTLDs): Como .com, .org, .net, .edu
- TLDs de Código de País (ccTLDs): Como .br (Brasil), .us (Estados Unidos), .jp (Japão)
- TLDs de Infraestrutura: Como .arpa, usado para infraestrutura da Internet
- TLDs Novos: Como .blog, .tech, .app, introduzidos em expansões recentes
Cada TLD é gerenciado por uma organização registradora designada.
3. Domínios de Segundo Nível
São os domínios que indivíduos e organizações registram sob um TLD, como google.com, wikipedia.org ou uol.com.br.
4. Subdomínios
Qualquer nível abaixo do domínio de segundo nível é considerado um subdomínio, como mail.example.com ou blog.example.com. Os subdomínios são gerenciados pela mesma entidade que controla o domínio principal ou podem ser delegados a terceiros.
5. Hosts Individuais
No nível mais baixo da hierarquia estão os hosts individuais, como www.example.com ou ftp.example.com.
Processo de Resolução DNS
Quando um cliente precisa resolver um nome de domínio, o processo geralmente segue estas etapas:
Consulta ao Resolver Local: O cliente envia a consulta para o resolver DNS configurado (geralmente fornecido pelo ISP ou configurado manualmente).
Cache do Resolver: O resolver verifica se a resposta está em seu cache. Se estiver e não tiver expirado (conforme o TTL), retorna imediatamente.
- Consulta Recursiva: Se não estiver em cache, o resolver inicia uma consulta recursiva:
- Consulta um servidor raiz para encontrar o servidor TLD responsável
- Consulta o servidor TLD para encontrar o servidor autoritativo para o domínio
- Consulta o servidor autoritativo para obter o registro específico
- Resposta ao Cliente: O resolver retorna a resposta ao cliente e a armazena em cache para consultas futuras.
Este processo é otimizado por caching em vários níveis, reduzindo a carga nos servidores autoritativos e melhorando o desempenho.
+----------+ Consulta +----------------+ Consulta +-------------+
| Cliente | -----------------> | Resolver Local | -----------------> | Servidor |
+----------+ (Cache?) +----------------+ (Recursiva) | Raiz (.) |
^ | +-------------+
| Resposta | Cache Miss |
| V V Referência TLD
| +-----------------------------------------------------------------+
| | |
| | Consulta +-------------+ Consulta +---------------+
| <---------------| Servidor | <----------------- | Servidor TLD |
| Resposta | Autoritativo| (Registro) | (.com, .org) |
| +-------------+ +---------------+
| ^ Referência Autoritativo
+-----------------------------------------------------------------+
Figura 2: Fluxograma simplificado do processo de resolução DNS
. (Root)
/|\
/ | \
/ | \
.com .org .br ... (TLDs)
| | |
example wikipedia uol ... (Second Level Domains)
/ | |
/ | |
www mail blog ... (Subdomains / Hosts)
Figura 1: Representação da hierarquia DNS
Tipos de Servidores DNS
Existem vários tipos de servidores DNS, cada um com funções específicas na infraestrutura global:
1. Servidores Autoritativos
São a fonte oficial de informações para zonas específicas. Eles respondem com informações definitivas sobre os domínios pelos quais são responsáveis.
Servidor Primário (Master)
- Mantém os arquivos de zona originais
- É onde as alterações são feitas diretamente
- Pode transferir zonas para servidores secundários
Servidor Secundário (Slave)
- Obtém cópias dos arquivos de zona do servidor primário
- Fornece redundância e balanceamento de carga
- Não aceita atualizações diretas nos arquivos de zona
- Sincroniza periodicamente com o primário
2. Servidores Recursivos
Realizam consultas completas em nome dos clientes, percorrendo a hierarquia DNS até encontrar a resposta autoritativa.
- Geralmente operados por ISPs, empresas ou serviços públicos (como 8.8.8.8 do Google)
- Mantêm um cache para melhorar o desempenho
- Implementam políticas de segurança e filtragem
3. Servidores Caching-Only
Similar aos recursivos, mas não são autoritativos para nenhuma zona.
- Focados apenas em armazenar respostas em cache
- Reduzem o tráfego de rede e melhoram o tempo de resposta
- Comumente usados em redes corporativas
4. Servidores Forwarding
Encaminham consultas para outros servidores DNS específicos.
- Simplificam a configuração de clientes
- Centralizam políticas de segurança
- Podem melhorar o desempenho em determinados cenários
5. Servidores Stub
Mantêm apenas informações sobre os servidores autoritativos para determinadas zonas.
- Mais leves que servidores secundários completos
- Úteis para delegações internas em grandes organizações
+----------+ Consulta +-----------+ Consulta +--------------+ Consulta +--------------+
| Cliente | ---------> | Recursivo | ---------> | Raiz/TLD/... | ---------> | Autoritativo |
+----------+ | (Cache) | +--------------+ | (Prim/Sec) |
+-----------+ +--------------+
| ^ | ^
| | Encaminha (Forwarding) | Transferência|
V | V de Zona |
+-----------+ +--------------+ |
| Forwarder | | Secundário |---+
+-----------+ +--------------+
|
V Consulta Externa
+-----------+
| Outro DNS |
+-----------+
Figura 3: Interação entre diferentes tipos de Servidores DNS
Conceitos de Zonas DNS
Uma zona DNS é uma porção do espaço de nomes de domínio gerenciada por uma entidade específica. É importante não confundir zonas com domínios - uma zona pode conter múltiplos domínios ou apenas parte de um domínio.
Tipos de Zonas
1. Zona Direta (Forward Zone)
Mapeia nomes de domínio para endereços IP e outros recursos. Por exemplo, a zona example.com contém registros que traduzem nomes como www.example.com para seus respectivos endereços IP.
2. Zona Reversa (Reverse Zone)
Mapeia endereços IP para nomes de domínio, essencial para verificações de autenticidade e troubleshooting. As zonas reversas usam o domínio especial in-addr.arpa para IPv4 e ip6.arpa para IPv6.
Por exemplo:
- Para a rede 192.168.200.0/24, a zona reversa seria 200.168.192.in-addr.arpa
- Para a rede IPv6 2001:db8::/32, a zona reversa seria 8.b.d.0.1.0.0.2.ip6.arpa
3. Zona Stub
Contém apenas os registros NS para os servidores autoritativos de uma zona, permitindo delegações eficientes.
4. Zona Hint
Contém informações sobre os servidores raiz do DNS, servindo como ponto de partida para consultas recursivas.
Delegação de Zonas
A delegação permite que partes do espaço de nomes sejam gerenciadas por diferentes entidades. Por exemplo, uma empresa pode delegar o subdomínio dev.example.com para o departamento de desenvolvimento.
A delegação é implementada através de registros NS no domínio pai, apontando para os servidores autoritativos do subdomínio.
Registros DNS Comuns
Os registros DNS (Resource Records) são as unidades básicas de informação no DNS. Cada registro tem um tipo que define seu propósito e formato. Vamos explorar os tipos mais comuns:
Registros Básicos
A (Address)
Mapeia um nome para um endereço IPv4.
1
www.example.com. IN A 192.168.200.10
AAAA (IPv6 Address)
Mapeia um nome para um endereço IPv6.
1
www.example.com. IN AAAA 2001:db8::1
CNAME (Canonical Name)
Cria um alias para outro nome de domínio.
1
ftp.example.com. IN CNAME www.example.com.
MX (Mail Exchange)
Define servidores de email para o domínio, com prioridade (número menor = maior prioridade).
1
2
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
NS (Name Server)
Define servidores de nomes autoritativos para o domínio.
1
2
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
PTR (Pointer)
Usado em zonas reversas para mapear IPs para nomes.
1
10.200.168.192.in-addr.arpa. IN PTR www.example.com.
SOA (Start of Authority)
Define parâmetros globais para a zona, incluindo serial, tempos de refresh, retry, expire e TTL mínimo.
1
2
3
4
5
6
7
example.com. IN SOA ns1.example.com. admin.example.com. (
2025051701 ; Serial
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
86400 ; Minimum TTL (1 day)
)
Registros para Segurança e Políticas
TXT (Text)
Armazena texto arbitrário, frequentemente usado para verificações de propriedade e políticas.
1
example.com. IN TXT "v=spf1 ip4:192.168.200.0/24 -all"
SPF (Sender Policy Framework)
Define servidores autorizados a enviar emails em nome do domínio (agora implementado como registro TXT).
1
example.com. IN TXT "v=spf1 mx ip4:192.168.200.0/24 -all"
DKIM (DomainKeys Identified Mail)
Fornece uma assinatura criptográfica para emails (implementado como registro TXT).
1
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
DMARC (Domain-based Message Authentication, Reporting & Conformance)
Define políticas para autenticação de email (implementado como registro TXT).
1
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Registros para Serviços e Funcionalidades Especiais
SRV (Service)
Define localização de serviços específicos, incluindo prioridade, peso, porta e host.
1
_ldap._tcp.example.com. IN SRV 0 1 389 ldap.example.com.
CAA (Certification Authority Authorization)
Especifica quais autoridades certificadoras podem emitir certificados para o domínio.
1
example.com. IN CAA 0 issue "letsencrypt.org"
TLSA (TLSA Certificate Association)
Associa um certificado TLS a um serviço, parte do DANE (DNS-based Authentication of Named Entities).
1
_443._tcp.www.example.com. IN TLSA 3 0 1 DEADBEEF...
Views no BIND: Separando Contextos Internos e Externos
O BIND suporta o conceito de “views” (visões), que permite apresentar diferentes respostas DNS dependendo da origem da consulta. Este recurso é particularmente útil em vários cenários:
1. DNS Split-Horizon (Horizonte Dividido)
Permite fornecer diferentes respostas para consultas internas e externas:
- Internamente: Revelar endereços IP privados (192.168.x.x, 10.x.x.x) e recursos internos
- Externamente: Mostrar apenas endereços IP públicos e recursos acessíveis pela internet
Isso é especialmente útil quando você tem serviços que precisam ser acessados tanto internamente quanto externamente, mas com endereços diferentes.
2. Segurança e Privacidade
As views ajudam a limitar a exposição de informações sobre sua infraestrutura interna:
- Ocultar servidores internos de consultas externas
- Revelar apenas o mínimo necessário para o funcionamento dos serviços públicos
- Reduzir a superfície de ataque ao limitar as informações disponíveis para reconhecimento
3. Otimização e Geolocalização
Permite direcionar usuários para servidores diferentes com base em sua localização ou rede:
- Direcionar usuários para o datacenter mais próximo
- Fornecer respostas otimizadas para diferentes redes ou regiões
- Implementar políticas específicas para diferentes grupos de usuários
Exemplo Simplificado de Views
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
view "internal" {
match-clients { 192.168.0.0/16; 10.0.0.0/8; };
zone "example.com" {
type master;
file "zones/internal/example.com.zone";
};
};
view "external" {
match-clients { any; };
zone "example.com" {
type master;
file "zones/external/example.com.zone";
};
};
Neste exemplo, clientes das redes 192.168.0.0/16 e 10.0.0.0/8 receberão respostas da zona interna, enquanto todos os outros clientes receberão respostas da zona externa.
+-----------------+ Consulta por www.example.com +-----------------+
| Cliente Interno | ---------------------------------------> | Servidor BIND |
| (192.168.1.10) | | com Views |
+-----------------+ +-------+---------+
| match-clients { internal_nets; }
V
+-----------------+
| Zona Interna |
| www -> 192.168.1.100 |
+-----------------+
|
V Resposta: 192.168.1.100
|
+-----------------+ Consulta por www.example.com +-------+---------+
| Cliente Externo | ---------------------------------------> | Servidor BIND |
| (203.0.113.5) | | com Views |
+-----------------+ +-------+---------+
| match-clients { any; }
V
+-----------------+
| Zona Externa |
| www -> 203.0.113.80 |
+-----------------+
|
V Resposta: 203.0.113.80
Figura 4: Exemplo simplificado de DNS Split-Horizon usando Views
Conceito de ACLs no BIND
As Listas de Controle de Acesso (ACLs) no BIND permitem definir grupos de endereços IP ou redes para aplicar políticas específicas. Elas são uma ferramenta poderosa para organização e segurança.
Usos Comuns de ACLs
1. Controle de Transferência de Zona
Limitar quais servidores podem solicitar transferências de zona (AXFR/IXFR):
1
2
3
4
5
6
7
8
9
10
acl secondary_servers {
192.168.200.50; // ns2
192.168.200.51; // ns3
};
zone "example.com" {
type master;
file "zones/example.com.zone";
allow-transfer { secondary_servers; };
};
2. Controle de Consultas
Definir quais clientes podem fazer consultas ao servidor:
1
2
3
4
5
6
7
8
9
acl trusted_networks {
192.168.0.0/16;
10.0.0.0/8;
localhost;
};
options {
allow-query { trusted_networks; };
};
3. Recursão Seletiva
Permitir recursão apenas para clientes específicos:
1
2
3
4
options {
recursion yes;
allow-recursion { trusted_networks; };
};
4. Aplicação de Views
Determinar qual view será apresentada a cada cliente:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
acl internal_networks {
192.168.0.0/16;
10.0.0.0/8;
localhost;
};
view "internal" {
match-clients { internal_networks; };
// Configuração da view interna
};
view "external" {
match-clients { any; };
// Configuração da view externa
};
ACLs Predefinidas
O BIND inclui algumas ACLs predefinidas:
- any: Corresponde a todos os hosts
- none: Não corresponde a nenhum host
- localhost: Corresponde ao(s) endereço(s) do host local
- localnets: Corresponde a todas as redes às quais o host local está diretamente conectado
Boas Práticas para ACLs
- Nomeie ACLs de forma descritiva: Use nomes que indiquem claramente o propósito ou conteúdo da ACL
- Defina ACLs no início do arquivo: Coloque-as antes de options e zonas para melhor organização
- Documente o propósito de cada ACL: Adicione comentários explicando o que cada ACL representa
- Mantenha ACLs atualizadas: Revise periodicamente para garantir que reflitam a topologia atual da rede
DNSSEC: Segurança no DNS
O DNSSEC (DNS Security Extensions) adiciona uma camada de segurança ao DNS através de assinaturas digitais, protegendo contra diversos ataques, como envenenamento de cache e spoofing.
O que o DNSSEC Proporciona
1. Autenticidade
Confirma que as respostas DNS vêm de servidores legítimos, não de impostores.
2. Integridade
Garante que os dados não foram alterados durante a transmissão.
3. Não-repúdio
Impede que servidores neguem ter enviado determinadas respostas.
O que o DNSSEC NÃO Faz
É importante entender as limitações do DNSSEC:
- Não criptografa o tráfego DNS (para isso, use DNS over TLS ou DNS over HTTPS)
- Não protege contra ataques de negação de serviço (DDoS)
- Não impede vazamento de informações sobre a zona
Como o DNSSEC Funciona
O DNSSEC funciona através de uma cadeia de confiança, começando na zona raiz e descendo pela hierarquia DNS:
- Assinatura de Registros: Cada registro em uma zona é assinado digitalmente pelo proprietário da zona
- Registros RRSIG: Contêm as assinaturas digitais para conjuntos de registros
- Registros DNSKEY: Contêm chaves públicas usadas para verificar as assinaturas
- Registros DS: Armazenados na zona pai, vinculam a zona filha à cadeia de confiança
- Validação: Resolvedores verificam a cadeia de assinaturas até a raiz
Tipos de Registros DNSSEC
RRSIG (Resource Record Signature)
Contém a assinatura digital para um conjunto de registros.
DNSKEY (DNS Public Key)
Contém a chave pública usada para verificar assinaturas RRSIG.
DS (Delegation Signer)
Armazenado na zona pai, identifica a chave usada para assinar os registros DNSKEY na zona filha.
NSEC/NSEC3 (Next Secure)
Prova criptográfica da não-existência de registros, prevenindo ataques de negação de existência.
Logging e Monitoramento
O monitoramento adequado do servidor DNS é crucial para operações confiáveis e seguras. O BIND oferece recursos avançados de logging que permitem categorizar e direcionar diferentes tipos de eventos.
Importância do Logging e Monitoramento
1. Detecção de Problemas
Identificar falhas antes que afetem os usuários, como:
- Erros de configuração
- Falhas de resolução
- Problemas de transferência de zona
2. Segurança
Detectar tentativas de ataque, como:
- DNS poisoning
- Ataques de amplificação
- Tentativas de transferência de zona não autorizadas
- Consultas suspeitas ou anômalas
3. Performance
Avaliar o desempenho e planejar capacidade:
- Volume de consultas
- Tempos de resposta
- Utilização de recursos
4. Troubleshooting
Facilitar a resolução de problemas:
- Rastrear consultas específicas
- Identificar padrões de erro
- Verificar propagação de alterações
Configuração Básica de Logging
O BIND permite configurar diferentes canais e categorias de log:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
logging {
channel default_log {
file "/var/log/named/bind.log" versions 3 size 5m;
severity info;
print-time yes;
print-category yes;
};
channel security_log {
file "/var/log/named/security.log" versions 3 size 5m;
severity info;
print-time yes;
print-category yes;
};
channel query_log {
file "/var/log/named/query.log" versions 3 size 10m;
severity info;
print-time yes;
};
category default { default_log; };
category security { security_log; };
category queries { query_log; };
};
SELinux e DNS
O Security-Enhanced Linux (SELinux) adiciona uma camada adicional de segurança através de políticas de controle de acesso mandatório. Para servidores DNS, o SELinux é uma ferramenta poderosa para reforçar a segurança.
Como o SELinux Protege Servidores DNS
1. Restringe Acesso a Arquivos
Limita quais arquivos o processo named pode acessar, usando contextos específicos:
- named_conf_t: Para arquivos de configuração
- named_zone_t: Para arquivos de zona
- named_cache_t: Para arquivos de cache
- named_log_t: Para arquivos de log
2. Controla Portas de Rede
Define quais portas o serviço pode utilizar:
- Por padrão, o BIND pode usar a porta 53 (TCP/UDP)
- Portas adicionais precisam ser explicitamente permitidas
3. Isola Processos
Limita a interação entre o serviço DNS e outros processos do sistema, reduzindo o impacto potencial de uma exploração.
Booleans SELinux para BIND
O SELinux usa “booleans” para controlar aspectos específicos do comportamento:
- named_write_master_zones: Permite que o BIND escreva em arquivos de zona primária
- named_tcp_bind_http_port: Permite que o BIND se vincule à porta HTTP (útil para estatísticas)
- named_bind_http_port: Similar ao anterior, mas para versões mais recentes do SELinux
Planejamento da Infraestrutura DNS
Antes de instalar e configurar o BIND, é essencial planejar cuidadosamente sua infraestrutura DNS. Um bom planejamento evita problemas futuros e facilita a manutenção.
Considerações de Planejamento
1. Topologia de Rede
- Redes Internas: Identifique todas as redes internas que precisarão de resolução DNS
- DMZ: Determine se você precisa de uma zona desmilitarizada para serviços públicos
- Conectividade Externa: Planeje como o DNS se integrará com a Internet
2. Arquitetura DNS
- Servidores Primários e Secundários: Determine quantos servidores você precisa e onde serão posicionados
- Views: Decida se você precisa de views separadas para redes internas e externas
- Recursão: Determine quais servidores fornecerão recursão e para quais clientes
3. Zonas e Domínios
- Domínios Internos: Escolha nomes de domínio para uso interno (evite usar domínios públicos internamente)
- Zonas Reversas: Planeje zonas reversas para todas as suas redes
- Delegações: Identifique se você precisará de delegações para subdomínios
4. Segurança
- DNSSEC: Decida se implementará DNSSEC e planeje o gerenciamento de chaves
- Transferências de Zona: Determine quais servidores podem solicitar transferências
- Controle de Acesso: Planeje ACLs para diferentes tipos de acesso
5. Monitoramento e Logging
- Estratégia de Logging: Decida quais eventos registrar e onde armazenar logs
- Rotação de Logs: Planeje a rotação e retenção de logs
- Monitoramento: Determine como monitorará a saúde e desempenho dos servidores DNS
Documentação da Infraestrutura
Documente cuidadosamente seu planejamento, incluindo:
- Diagrama da topologia DNS
- Lista de servidores com funções e endereços IP
- Esquema de nomeação para hosts e domínios
- Políticas de segurança e acesso
- Procedimentos de manutenção e recuperação
Requisitos para Instalação no Oracle Linux 9
Antes de instalar o BIND no Oracle Linux 9, verifique se seu ambiente atende aos requisitos necessários.
Requisitos de Hardware
Os requisitos de hardware para um servidor DNS dependem do volume de consultas e do número de zonas:
Para Ambientes Pequenos a Médios
- CPU: 2+ cores
- RAM: 2-4 GB
- Armazenamento: 20+ GB (principalmente para logs)
- Rede: Interface de rede confiável, preferencialmente redundante
Para Ambientes Grandes ou de Alta Carga
- CPU: 4+ cores
- RAM: 8+ GB
- Armazenamento: 50+ GB com bom desempenho de I/O
- Rede: Interfaces redundantes de alta velocidade
Requisitos de Software
- Sistema Operacional: Oracle Linux 9 (kernel UEK ou RHCK)
- Atualizações: Sistema totalmente atualizado
- Pacotes Adicionais: Dependências serão instaladas automaticamente
Requisitos de Rede
- Endereços IP: Endereços IP estáticos para todos os servidores DNS
- Conectividade: Acesso à Internet para atualizações e resolução externa
- Portas: Porta 53 (TCP e UDP) aberta para clientes que precisam de resolução
- Firewall: Configurado para permitir tráfego DNS necessário
Requisitos de Segurança
- SELinux: Preferencialmente em modo enforcing (padrão no OL9)
- Firewall: firewalld ou iptables configurado e ativo
- Atualizações: Sistema de atualizações regulares implementado
- Monitoramento: Sistema básico de monitoramento em funcionamento
Preparação do Ambiente
Antes de instalar o BIND, vamos preparar o ambiente Oracle Linux 9.
Atualização do Sistema
Primeiro, atualize o sistema para garantir que você tenha as versões mais recentes de todos os pacotes:
1
sudo dnf update -y
Configuração de Hostname e Rede
Certifique-se de que o hostname está configurado corretamente:
1
sudo hostnamectl set-hostname ns1.example.com
Verifique a configuração de rede e garanta que o servidor tenha um endereço IP estático:
1
2
3
4
5
6
sudo nmcli connection show
sudo nmcli connection modify ens3 ipv4.addresses 192.168.200.49/24
sudo nmcli connection modify ens3 ipv4.gateway 192.168.200.1
sudo nmcli connection modify ens3 ipv4.dns "8.8.8.8 8.8.4.4"
sudo nmcli connection modify ens3 ipv4.method manual
sudo nmcli connection up ens3
Configuração do Firewall
Configure o firewall para permitir o tráfego DNS:
1
2
sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload
Verifique se as regras foram aplicadas:
1
sudo firewall-cmd --list-all
Configuração de SELinux
Verifique se o SELinux está ativo:
1
sudo sestatus
O resultado deve mostrar que o SELinux está em modo enforcing. Não desative o SELinux, pois ele fornece uma camada importante de segurança.
Configuração de NTP
É crucial que os servidores DNS tenham o horário sincronizado. Configure o NTP:
1
2
3
sudo dnf install chrony -y
sudo systemctl enable chronyd
sudo systemctl start chronyd
Verifique a sincronização:
1
chronyc sources
Criação de Diretórios para Logs
Crie um diretório para os logs do BIND:
1
sudo mkdir -p /var/log/named
Os diretórios para zonas e outros arquivos serão criados durante a instalação e configuração do BIND.
Conclusão e Próximos Passos
Neste primeiro artigo da série, exploramos os fundamentos do DNS, incluindo sua importância, hierarquia, tipos de servidores e registros. Também abordamos conceitos importantes como views, ACLs, DNSSEC e SELinux, e preparamos o ambiente para a instalação do BIND no Oracle Linux 9.
Com essa base sólida, estamos prontos para prosseguir com a instalação e configuração básica do BIND, que será o tema do próximo artigo da série.
O que vem a seguir?
No próximo artigo, “Instalação e Configuração Básica do BIND no Oracle Linux 9”, abordaremos:
- Instalação dos pacotes BIND e utilitários
- Estrutura de diretórios e arquivos
- Configuração básica do named.conf
- Definição de ACLs e opções globais
- Inicialização e verificação do serviço
- Testes iniciais de funcionamento
Não perca! A jornada para dominar o DNS BIND no Oracle Linux 9 está apenas começando.