Configuração de Zonas DNS no BIND: Diretas e Reversas
Este é o terceiro artigo de nossa série sobre implementação e configuração do DNS BIND no Oracle Linux 9. No primeiro artigo, abordamos os conceitos fundamentais do DNS e a preparação do ambiente. No segundo artigo, realizamos a instalação e configuração básica do servidor DNS. Agora, vamos avançar para a configuração de zonas DNS.
Introdução
As zonas DNS são o coração de qualquer servidor DNS autoritativo. Elas contêm os registros que mapeiam nomes de domínio para endereços IP e outros recursos, permitindo que o servidor responda a consultas com informações autoritativas sobre os domínios que gerencia.
Neste artigo, vamos explorar em detalhes como criar e configurar zonas DNS no BIND, tanto zonas diretas (forward zones) quanto zonas reversas (reverse zones). Abordaremos a estrutura e sintaxe dos arquivos de zona, os diferentes tipos de registros DNS e como verificar e testar a configuração.
Ao final deste tutorial, você terá um servidor DNS completamente funcional, capaz de resolver nomes para IPs (resolução direta) e IPs para nomes (resolução reversa) para seus domínios.
Conceitos Fundamentais de Zonas DNS
Antes de mergulharmos na configuração prática, vamos revisar alguns conceitos fundamentais sobre zonas DNS.
Tipos de Zonas
Como mencionamos no primeiro artigo da série, existem diferentes tipos de zonas:
- Zonas Diretas (Forward Zones): Mapeiam nomes de domínio para endereços IP e outros recursos
- Zonas Reversas (Reverse Zones): Mapeiam endereços IP para nomes de domínio
- Zonas Stub: Contêm apenas os registros NS para os servidores autoritativos de uma zona
- Zonas Hint: Contêm informações sobre os servidores raiz do DNS
Neste artigo, focaremos nas zonas diretas e reversas, que são as mais comuns e essenciais.
Tipos de Registros DNS
Os registros DNS (Resource Records) são as unidades básicas de informação em uma zona DNS. Cada registro tem um tipo que define seu propósito e formato. Revisaremos os tipos mais comuns:
- SOA (Start of Authority): Define parâmetros globais para a zona
- NS (Name Server): Define servidores de nomes autoritativos para a zona
- A: Mapeia um nome para um endereço IPv4
- AAAA: Mapeia um nome para um endereço IPv6
- CNAME (Canonical Name): Cria um alias para outro nome de domínio
- MX (Mail Exchange): Define servidores de email para o domínio
- PTR (Pointer): Usado em zonas reversas para mapear IPs para nomes
- TXT (Text): Armazena texto arbitrário, frequentemente usado para verificações e políticas
- SRV (Service): Define localização de serviços específicos
Estrutura de um Arquivo de Zona
Um arquivo de zona típico segue esta estrutura:
- Diretivas de Controle: Como $TTL (Time To Live) e $ORIGIN
- Registro SOA: Define parâmetros globais para a zona
- Registros NS: Definem os servidores de nomes autoritativos
- Registros MX: Definem os servidores de email (opcional)
- Outros Registros: A, AAAA, CNAME, TXT, etc.
+-----------------------------------------------------+
| ; Comentários começam com ponto e vírgula |
+-----------------------------------------------------+
| $TTL 86400 ; Diretiva: TTL Padrão |
| $ORIGIN example.com. ; Diretiva: Domínio Base |
+-----------------------------------------------------+
| @ IN SOA ns1.example.com. admin.example.com. ( |
| 2025051901 ; Serial |
| 10800 ; Refresh |
| 3600 ; Retry |
| 604800 ; Expire |
| 86400 ; Minimum TTL |
| ) ; Registro SOA (Obrigatório)|
+-----------------------------------------------------+
| IN NS ns1.example.com. ; Registros NS |
| IN NS ns2.example.com. ; (Servidores de Nomes) |
+-----------------------------------------------------+
| IN MX 10 mail.example.com. ; Registros MX |
| IN MX 20 mail2.example.com. ; (Servidores Email)|
+-----------------------------------------------------+
| www IN A 192.168.200.10 ; Registros A (IPv4) |
| ns1 IN A 192.168.200.49 ; |
+-----------------------------------------------------+
| www IN AAAA 2001:db8::10 ; Registros AAAA (IPv6) |
+-----------------------------------------------------+
| ftp IN CNAME www ; Registros CNAME (Alias)|
+-----------------------------------------------------+
| @ IN TXT "v=spf1..." ; Registros TXT (Texto) |
+-----------------------------------------------------+
| ... outros registros (SRV, PTR em reversa, etc.) |
+-----------------------------------------------------+
Figura 1: Estrutura típica de um arquivo de zona DNS
Planejamento de Zonas
Antes de começar a criar zonas, é importante planejar cuidadosamente quais zonas você precisará e quais registros cada uma conterá.
Exemplo de Planejamento
Para este tutorial, vamos usar o seguinte cenário:
- Domínio Principal: example.com
- Rede Interna: 192.168.200.0/24
- Rede DMZ: 172.16.0.0/24
- Rede Pública: 203.0.113.0/24 (exemplo de endereço público)
- Rede IPv6: 2001:db8::/64 (exemplo de endereço IPv6)
Com base neste cenário, precisaremos das seguintes zonas:
- Zona Direta: example.com
- Zona Reversa IPv4 (Interna): 200.168.192.in-addr.arpa
- Zona Reversa IPv4 (DMZ): 0.16.172.in-addr.arpa
- Zona Reversa IPv4 (Pública): 113.0.203.in-addr.arpa
- Zona Reversa IPv6: 8.b.d.0.1.0.0.2.ip6.arpa
Configuração de Zonas Diretas
Vamos começar configurando uma zona direta para o domínio example.com.
+-----------------------+ Consulta Direta +-----------------------+
| Nome: www.example.com | ------------------------> | IP: 192.168.200.10 |
+-----------------------+ +-----------------------+
^ |
| Mapeamento (Registro A/AAAA) |
+---------------------------------------------------+
+-----------------------+ Consulta Reversa +-----------------------+
| Nome: www.example.com | <------------------------ | IP: 192.168.200.10 |
+-----------------------+ +-----------------------+
| ^
| Mapeamento (Registro PTR em zona reversa) |
+---------------------------------------------------+
(Zona: 200.168.192.in-addr.arpa)
Figura 2: Comparação entre resolução direta e reversa
Definição da Zona no named.conf
Primeiro, precisamos definir a zona no arquivo de configuração principal do BIND. Edite o arquivo /etc/named.conf:
1
sudo vi /etc/named.conf
Adicione a definição da zona ao final do arquivo, antes das inclusões de arquivos padrão:
1
2
3
4
5
6
7
8
9
// ================================================================================
// Forward Zones
// ================================================================================
zone "example.com" IN {
type master;
file "zones/example.com.zone";
allow-transfer { dns_servers; };
allow-update { none; };
};
Esta configuração define:
- O nome da zona: “example.com”
- O tipo da zona: “master” (primária)
- O arquivo que contém os registros da zona: “zones/example.com.zone”
- Quem pode solicitar transferências de zona: apenas os servidores definidos na ACL “dns_servers”
- Quem pode atualizar a zona dinamicamente: ninguém
Criação do Arquivo de Zona
Agora, vamos criar o arquivo de zona para example.com:
1
sudo vi /var/named/zones/example.com.zone
Adicione o seguinte conteúdo:
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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
; Zone file for example.com
$TTL 86400 ; 1 day default TTL
$ORIGIN example.com.
; SOA Record
@ IN SOA ns1.example.com. admin.example.com. (
2025051901 ; Serial
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
86400 ; Minimum TTL (1 day)
)
; NS Records
IN NS ns1.example.com.
IN NS ns2.example.com.
; MX Records
IN MX 10 mail.example.com.
IN MX 20 mail2.example.com.
; A Records for Name Servers
ns1 IN A 192.168.200.49
ns2 IN A 192.168.200.50
; A Records for Mail Servers
mail IN A 192.168.200.20
mail2 IN A 192.168.200.21
; A Records for Web Servers
www IN A 192.168.200.10
IN A 192.168.200.11 ; Round-robin DNS for load balancing
; AAAA Records (IPv6)
ns1 IN AAAA 2001:db8::49
ns2 IN AAAA 2001:db8::50
www IN AAAA 2001:db8::10
mail IN AAAA 2001:db8::20
; CNAME Records
ftp IN CNAME www
webmail IN CNAME mail
; TXT Records
@ IN TXT "v=spf1 mx ip4:192.168.200.0/24 -all"
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
; SRV Records
_ldap._tcp IN SRV 0 1 389 ldap.example.com.
_kerberos._udp IN SRV 0 1 88 kdc.example.com.
Explicação do Arquivo de Zona
Vamos analisar cada seção do arquivo de zona:
Diretivas de Controle
1
2
$TTL 86400 ; 1 day default TTL
$ORIGIN example.com.
- $TTL: Define o Time To Live padrão para registros que não especificam um TTL próprio
- $ORIGIN: Define o domínio base para nomes relativos no arquivo
Registro SOA (Start of Authority)
1
2
3
4
5
6
7
@ IN SOA ns1.example.com. admin.example.com. (
2025051901 ; Serial
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
86400 ; Minimum TTL (1 day)
)
O registro SOA contém informações administrativas sobre a zona:
- @: Representa o domínio base ($ORIGIN)
- ns1.example.com.: O servidor DNS primário para a zona
- admin.example.com.: O endereço de email do administrador (com @ substituído por .)
- Serial: Número de versão do arquivo de zona, geralmente no formato YYYYMMDDnn
- Refresh: Intervalo em que servidores secundários verificam atualizações
- Retry: Intervalo para nova tentativa após falha de atualização
- Expire: Tempo após o qual a zona é considerada inválida se não for atualizada
- Minimum TTL: TTL mínimo para registros negativos (NXDOMAIN)
Nota: É crucial incrementar o número serial sempre que você fizer alterações no arquivo de zona. Isso garante que servidores secundários detectem e apliquem as alterações.
Registros NS (Name Server)
1
2
IN NS ns1.example.com.
IN NS ns2.example.com.
Estes registros definem os servidores de nomes autoritativos para o domínio.
Registros MX (Mail Exchange)
1
2
IN MX 10 mail.example.com.
IN MX 20 mail2.example.com.
Estes registros definem os servidores de email para o domínio, com prioridades (10 é maior prioridade que 20).
Registros A e AAAA
1
2
ns1 IN A 192.168.200.49
ns1 IN AAAA 2001:db8::49
Estes registros mapeiam nomes para endereços IPv4 (A) e IPv6 (AAAA).
Registros CNAME (Canonical Name)
1
ftp IN CNAME www
Este registro cria um alias “ftp” que aponta para “www”.
Registros TXT (Text)
1
@ IN TXT "v=spf1 mx ip4:192.168.200.0/24 -all"
Este registro define uma política SPF (Sender Policy Framework) para o domínio.
Registros SRV (Service)
1
_ldap._tcp IN SRV 0 1 389 ldap.example.com.
Este registro define a localização do serviço LDAP, incluindo prioridade (0), peso (1), porta (389) e host (ldap.example.com).
Definição de Permissões e Contexto SELinux
Após criar o arquivo de zona, precisamos definir as permissões e o contexto SELinux corretos:
1
2
3
sudo chown root:named /var/named/zones/example.com.zone
sudo chmod 640 /var/named/zones/example.com.zone
sudo restorecon -v /var/named/zones/example.com.zone
Verificação da Sintaxe da Zona
Antes de recarregar o servidor DNS, é importante verificar a sintaxe do arquivo de zona:
1
sudo named-checkzone example.com /var/named/zones/example.com.zone
Se a zona estiver correta, você verá uma mensagem como:
1
2
zone example.com/IN: loaded serial 2025051901
OK
Configuração de Zonas Reversas
As zonas reversas permitem a resolução reversa, ou seja, a tradução de endereços IP para nomes de domínio. Isso é importante para várias aplicações, incluindo logs, autenticação e verificações de segurança.
Zonas Reversas para IPv4
Para redes IPv4, as zonas reversas usam o domínio especial in-addr.arpa. O nome da zona é formado invertendo os octetos do endereço de rede e adicionando o sufixo in-addr.arpa.
Por exemplo, para a rede 192.168.200.0/24, a zona reversa seria 200.168.192.in-addr.arpa.
Definição da Zona Reversa no named.conf
Adicione a definição da zona reversa ao arquivo /etc/named.conf:
1
2
3
4
5
6
7
8
9
// ================================================================================
// Reverse Zones
// ================================================================================
zone "200.168.192.in-addr.arpa" IN {
type master;
file "zones/200.168.192.in-addr.arpa.zone";
allow-transfer { dns_servers; };
allow-update { none; };
};
Criação do Arquivo de Zona Reversa
Crie o arquivo de zona reversa:
1
sudo vi /var/named/zones/200.168.192.in-addr.arpa.zone
Adicione o seguinte conteúdo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
; Reverse zone file for 192.168.200.0/24
$TTL 86400 ; 1 day default TTL
$ORIGIN 200.168.192.in-addr.arpa.
; SOA Record
@ IN SOA ns1.example.com. admin.example.com. (
2025051901 ; Serial
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
86400 ; Minimum TTL (1 day)
)
; NS Records
IN NS ns1.example.com.
IN NS ns2.example.com.
; PTR Records
10 IN PTR www.example.com.
11 IN PTR www.example.com.
20 IN PTR mail.example.com.
21 IN PTR mail2.example.com.
49 IN PTR ns1.example.com.
50 IN PTR ns2.example.com.
Explicação do Arquivo de Zona Reversa
A estrutura do arquivo de zona reversa é similar à da zona direta, com algumas diferenças:
- O $ORIGIN é o nome da zona reversa (200.168.192.in-addr.arpa.)
- Em vez de registros A/AAAA, usamos registros PTR (Pointer)
- Os nomes à esquerda são os últimos octetos dos endereços IP
Por exemplo, o registro:
1
10 IN PTR www.example.com.
Mapeia o endereço IP 192.168.200.10 para o nome www.example.com.
Zonas Reversas para IPv6
Para redes IPv6, as zonas reversas usam o domínio especial ip6.arpa. O processo é similar ao IPv4, mas com uma diferença importante: cada dígito hexadecimal do endereço IPv6 se torna um nível na hierarquia DNS, e a ordem é invertida.
Por exemplo, para a rede 2001:db8::/64, a zona reversa seria 8.b.d.0.1.0.0.2.ip6.arpa.
Definição da Zona Reversa IPv6 no named.conf
1
2
3
4
5
6
zone "8.b.d.0.1.0.0.2.ip6.arpa" IN {
type master;
file "zones/8.b.d.0.1.0.0.2.ip6.arpa.zone";
allow-transfer { dns_servers; };
allow-update { none; };
};
Criação do Arquivo de Zona Reversa IPv6
1
sudo vi /var/named/zones/8.b.d.0.1.0.0.2.ip6.arpa.zone
Adicione o seguinte conteúdo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
; Reverse zone file for 2001:db8::/64
$TTL 86400 ; 1 day default TTL
$ORIGIN 8.b.d.0.1.0.0.2.ip6.arpa.
; SOA Record
@ IN SOA ns1.example.com. admin.example.com. (
2025051901 ; Serial
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
86400 ; Minimum TTL (1 day)
)
; NS Records
IN NS ns1.example.com.
IN NS ns2.example.com.
; PTR Records
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.example.com.
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail.example.com.
9.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.example.com.
0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.example.com.
Nota: A notação para registros PTR IPv6 pode ser bastante extensa. Algumas implementações do BIND suportam uma notação mais curta usando o caractere \, mas a notação completa é mais compatível.
Definição de Permissões e Contexto SELinux para Zonas Reversas
Como fizemos para a zona direta, precisamos definir as permissões e o contexto SELinux corretos para os arquivos de zona reversa:
1
2
3
4
5
6
7
sudo chown root:named /var/named/zones/200.168.192.in-addr.arpa.zone
sudo chmod 640 /var/named/zones/200.168.192.in-addr.arpa.zone
sudo restorecon -v /var/named/zones/200.168.192.in-addr.arpa.zone
sudo chown root:named /var/named/zones/8.b.d.0.1.0.0.2.ip6.arpa.zone
sudo chmod 640 /var/named/zones/8.b.d.0.1.0.0.2.ip6.arpa.zone
sudo restorecon -v /var/named/zones/8.b.d.0.1.0.0.2.ip6.arpa.zone
Verificação da Sintaxe das Zonas Reversas
Verifique a sintaxe dos arquivos de zona reversa:
1
2
sudo named-checkzone 200.168.192.in-addr.arpa /var/named/zones/200.168.192.in-addr.arpa.zone
sudo named-checkzone 8.b.d.0.1.0.0.2.ip6.arpa /var/named/zones/8.b.d.0.1.0.0.2.ip6.arpa.zone
Recarregando o Servidor DNS
Após configurar todas as zonas e verificar sua sintaxe, precisamos recarregar o servidor DNS para que as alterações entrem em vigor:
1
sudo rndc reload
Ou, se preferir reiniciar o serviço:
1
sudo systemctl restart named
Verificação e Testes
Agora que configuramos as zonas e recarregamos o servidor DNS, vamos realizar alguns testes para verificar se tudo está funcionando corretamente.
Teste de Resolução Direta
Vamos testar a resolução de nomes para IPs:
1
dig @localhost ns1.example.com
Você deve ver uma resposta como:
1
2
;; ANSWER SECTION:
ns1.example.com. 86400 IN A 192.168.200.49
Teste outros registros:
1
2
3
dig @localhost www.example.com
dig @localhost mail.example.com
dig @localhost example.com MX
Teste de Resolução Reversa
Agora, vamos testar a resolução reversa (IP para nome):
1
dig @localhost -x 192.168.200.49
Você deve ver uma resposta como:
1
2
;; ANSWER SECTION:
49.200.168.192.in-addr.arpa. 86400 IN PTR ns1.example.com.
Teste outros endereços IP:
1
2
dig @localhost -x 192.168.200.10
dig @localhost -x 192.168.200.20
Teste de Resolução IPv6
Se você configurou zonas IPv6, teste-as também:
1
2
dig @localhost AAAA ns1.example.com
dig @localhost -x 2001:db8::49
Verificação de Transferência de Zona
Para verificar se a transferência de zona está funcionando corretamente (e restrita aos servidores autorizados), tente solicitar uma transferência de zona:
1
dig @localhost example.com AXFR
Se suas ACLs estiverem configuradas corretamente, esta solicitação deve falhar a menos que seja feita de um servidor autorizado.
Técnicas Avançadas de Configuração de Zonas
Agora que dominamos as configurações básicas de zonas, vamos explorar algumas técnicas avançadas.
Uso de $GENERATE para Grandes Blocos de Registros
A diretiva $GENERATE permite criar múltiplos registros similares de forma eficiente. Isso é especialmente útil para zonas reversas com muitos registros.
Exemplo para uma zona reversa:
1
2
; Gerar PTR records para hosts de 1 a 100
$GENERATE 1-100 $ IN PTR host-$.example.com.
Isso gera registros PTR para host-1.example.com até host-100.example.com.
Para IPv6, você pode usar:
1
2
; Gerar PTR records para hosts IPv6
$GENERATE 1-100 $ IN PTR host-$.example.com.
Inclusão de Arquivos
Para organizar melhor arquivos de zona grandes, você pode usar a diretiva $INCLUDE para dividir o arquivo em partes menores:
1
2
3
4
5
; Incluir arquivo com registros de servidores web
$INCLUDE /var/named/zones/example.com.web.zone
; Incluir arquivo com registros de servidores de email
$INCLUDE /var/named/zones/example.com.mail.zone
Wildcards
Os wildcards permitem criar registros que correspondem a múltiplos subdomínios:
1
2
; Wildcard para subdomínios
*.example.com. IN A 192.168.200.100
Este registro fará com que qualquer subdomínio não definido explicitamente (como random.example.com) seja resolvido para 192.168.200.100.
Nota: Use wildcards com cautela, pois podem causar comportamentos inesperados e problemas de segurança se mal configurados.
TTLs Específicos por Registro
Embora tenhamos definido um TTL padrão com a diretiva $TTL, você pode especificar TTLs diferentes para registros individuais:
1
2
; Registro com TTL específico (300 segundos = 5 minutos)
www 300 IN A 192.168.200.10
Isso é útil para registros que mudam com frequência e precisam de um TTL menor.
Configuração de Zonas em Views
Se você estiver usando views (como discutimos no artigo anterior para implementar DNS Split-Horizon), a configuração de zonas é ligeiramente diferente. As zonas são definidas dentro dos blocos de view, não no nível global.
Exemplo de Configuração com Views
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
26
27
28
29
30
31
32
33
34
view "internal" {
match-clients { internal_networks; };
zone "example.com" IN {
type master;
file "zones/internal/example.com.zone";
allow-transfer { dns_servers; };
};
zone "200.168.192.in-addr.arpa" IN {
type master;
file "zones/internal/200.168.192.in-addr.arpa.zone";
allow-transfer { dns_servers; };
};
// Include standard zones
include "/etc/named.rfc1912.zones";
};
view "external" {
match-clients { any; };
zone "example.com" IN {
type master;
file "zones/external/example.com.zone";
allow-transfer { dns_servers; };
};
zone "113.0.203.in-addr.arpa" IN {
type master;
file "zones/external/113.0.203.in-addr.arpa.zone";
allow-transfer { dns_servers; };
};
};
Nesta configuração:
- A view “internal” contém zonas com informações internas (usando endereços IP privados)
- A view “external” contém zonas com informações públicas (usando endereços IP públicos)
- As zonas têm o mesmo nome, mas arquivos diferentes
Estrutura de Diretórios para Views
Para organizar melhor os arquivos de zona quando usando views, é recomendável criar uma estrutura de diretórios separada para cada view:
1
2
sudo mkdir -p /var/named/zones/internal
sudo mkdir -p /var/named/zones/external
Atualizações Dinâmicas
O BIND suporta atualizações dinâmicas, permitindo que registros DNS sejam adicionados, modificados ou removidos sem editar manualmente os arquivos de zona. Isso é útil para integração com DHCP e outros sistemas automatizados.
Configuração de Atualizações Dinâmicas
Para permitir atualizações dinâmicas, você precisa:
- Definir quem pode atualizar a zona
- Configurar uma chave de autenticação
Exemplo de configuração:
1
2
3
4
5
6
7
8
9
10
11
12
13
// Definição da chave
key "dhcp-key" {
algorithm hmac-sha256;
secret "your-base64-encoded-secret-key";
};
// Configuração da zona
zone "example.com" IN {
type master;
file "zones/example.com.zone";
allow-transfer { dns_servers; };
allow-update { key dhcp-key; };
};
Geração de Chave para Atualizações Dinâmicas
Para gerar uma chave segura:
1
sudo dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST dhcp-key
Este comando gera dois arquivos: Kdhcp-key.+xxx+yyyyy.key e Kdhcp-key.+xxx+yyyyy.private. O arquivo .key contém a chave pública, e o arquivo .private contém a chave privada.
Extraia a chave do arquivo .private:
1
sudo cat Kdhcp-key.*.private | grep Key
Use esta chave no campo “secret” da definição da chave.
Troubleshooting de Zonas DNS
Mesmo com uma configuração cuidadosa, problemas podem surgir. Aqui estão algumas situações comuns e como resolvê-las:
Problema: Zona Não Carrega
Verificação:
1
sudo rndc zonestatus example.com
Possíveis soluções:
- Verifique a sintaxe do arquivo de zona:
sudo named-checkzone example.com /var/named/zones/example.com.zone - Verifique permissões e contexto SELinux:
ls -laZ /var/named/zones/example.com.zone - Verifique logs:
sudo tail -f /var/log/named/general.log
Problema: Resolução Direta Funciona, mas Reversa Não
Verificação:
1
dig @localhost -x 192.168.200.49
Possíveis soluções:
- Verifique se a zona reversa está definida corretamente no named.conf
- Verifique a sintaxe do arquivo de zona reversa
- Verifique se os registros PTR estão corretos (formato e nomes de domínio)
Problema: Transferência de Zona Falha
Verificação:
1
dig @primary_server example.com AXFR
Possíveis soluções:
- Verifique as ACLs allow-transfer no servidor primário
- Verifique a conectividade de rede entre os servidores
- Verifique logs em ambos os servidores
Problema: Atualizações Dinâmicas Falham
Verificação:
1
2
3
4
5
nsupdate -k Kdhcp-key.+xxx+yyyyy.private
> server localhost
> zone example.com
> update add test.example.com 300 A 192.168.200.123
> send
Possíveis soluções:
- Verifique a configuração allow-update na zona
- Verifique se a chave está correta
- Verifique permissões do arquivo de zona (named precisa poder escrever nele)
- Verifique o boolean SELinux named_write_master_zones:
sudo getsebool named_write_master_zones
Melhores Práticas para Configuração de Zonas
Para finalizar, aqui estão algumas melhores práticas para configuração de zonas DNS:
1. Organização e Documentação
- Use comentários extensivamente nos arquivos de zona
- Agrupe registros por tipo ou função
- Mantenha uma documentação separada das zonas e registros
- Use nomes de arquivo consistentes e descritivos
2. Segurança
- Restrinja transferências de zona apenas a servidores secundários autorizados
- Use TSIG ou outras formas de autenticação para transferências de zona
- Implemente DNSSEC para zonas importantes
- Limite atualizações dinâmicas apenas a hosts autorizados
3. Manutenção
- Incremente o número serial sempre que fizer alterações
- Use um formato de serial consistente (YYYYMMDDNN é recomendado)
- Mantenha backups regulares dos arquivos de zona
- Documente todas as alterações em um log de mudanças
4. Desempenho
- Use TTLs apropriados para diferentes tipos de registros
- Considere TTLs menores para registros que mudam com frequência
- Use $GENERATE para grandes blocos de registros similares
- Divida zonas muito grandes em zonas menores quando apropriado
Conclusão e Próximos Passos
Neste terceiro artigo da série, configuramos zonas DNS diretas e reversas, exploramos a estrutura e sintaxe dos arquivos de zona, implementamos diferentes tipos de registros DNS e aprendemos técnicas avançadas de configuração de zonas.
Agora temos um servidor DNS completamente funcional, capaz de resolver nomes para IPs e IPs para nomes para nossos domínios. Esta é a base para configurações mais avançadas que abordaremos nos próximos artigos.
O que vem a seguir?
No próximo artigo, “Views e DNS Split-Horizon no BIND”, abordaremos em detalhes:
- Conceito e benefícios das views no BIND
- Implementação de DNS Split-Horizon
- Configuração de view interna para redes locais
- Configuração de view externa para internet
- Testes e validação de diferentes views
Não perca! Nossa jornada para dominar o DNS BIND no Oracle Linux 9 continua.