Post

Views e DNS Split-Horizon no BIND

Posted
By Gean Martins
28 min read
Views e DNS Split-Horizon no BIND

Este é o quarto artigo de nossa série sobre implementação e configuração do DNS BIND no Oracle Linux 9. Nos artigos anteriores, abordamos os conceitos fundamentais do DNS, a instalação e configuração básica e a configuração de zonas DNS. Agora, vamos explorar um dos recursos mais poderosos do BIND: as views e a implementação de DNS Split-Horizon.

Introdução

Em muitos ambientes de rede, especialmente em organizações com presença na Internet, é comum a necessidade de apresentar diferentes respostas DNS dependendo da origem da consulta. Por exemplo, um servidor web pode ser acessado internamente pelo endereço IP privado 192.168.200.10, mas externamente pelo endereço IP público 203.0.113.10.

O BIND oferece um recurso poderoso chamado “views” (visões) que permite configurar exatamente esse comportamento. Com views, você pode definir diferentes “visões” do seu espaço DNS, apresentando informações diferentes para consultas internas e externas. Esta técnica é conhecida como DNS Split-Horizon ou Split-View DNS.

Neste artigo, vamos explorar em detalhes como implementar views no BIND, configurar DNS Split-Horizon e garantir que as consultas sejam respondidas corretamente dependendo de sua origem.

Conceito e Benefícios das Views no BIND

As views no BIND permitem definir diferentes conjuntos de zonas e opções de configuração que serão apresentados a diferentes clientes com base em critérios como endereço IP de origem, porta, TSIG key ou outros atributos.

O que são Views?

Uma view é essencialmente um contexto de resolução DNS. Cada view pode conter:

  • Seu próprio conjunto de zonas
  • Suas próprias opções de configuração
  • Suas próprias ACLs (Access Control Lists)
  • Suas próprias regras de recursão

O BIND processa as views na ordem em que aparecem no arquivo de configuração, e a primeira view que corresponde aos critérios do cliente é a que será usada para responder à consulta.

Benefícios das Views

A implementação de views oferece diversos benefícios:

1. Segurança e Privacidade

  • Oculta informações internas de consultas externas
  • Limita a exposição da topologia de rede interna
  • Reduz a superfície de ataque ao expor apenas o necessário

2. Flexibilidade Operacional

  • Permite manter servidores internos e externos em uma única infraestrutura DNS
  • Facilita a migração e manutenção de serviços
  • Permite implementar políticas diferentes para diferentes redes

3. Otimização de Tráfego

  • Direciona usuários para servidores mais próximos ou menos carregados
  • Implementa balanceamento de carga baseado na origem da consulta
  • Otimiza o roteamento de tráfego para diferentes datacenters

4. Conformidade e Requisitos Específicos

  • Atende a requisitos regulatórios de separação de ambientes
  • Implementa políticas específicas para diferentes departamentos ou filiais
  • Adapta respostas DNS para diferentes provedores de serviços

DNS Split-Horizon: Conceito e Casos de Uso

O DNS Split-Horizon (também conhecido como Split-View DNS, Split-Brain DNS ou Horizon Splitting) é uma técnica que utiliza views para fornecer diferentes respostas DNS dependendo da origem da consulta.

Conceito Básico

No DNS Split-Horizon, o mesmo nome de domínio é resolvido para diferentes endereços IP ou recursos, dependendo de onde a consulta se origina:

  • Consultas de redes internas recebem respostas com endereços IP privados e informações completas sobre recursos internos
  • Consultas de redes externas (Internet) recebem respostas com endereços IP públicos e apenas informações sobre recursos acessíveis externamente

Casos de Uso Comuns

1. Acesso a Serviços Internos e Externos

Um cenário típico é um servidor web que precisa ser acessível tanto interna quanto externamente:

  • Internamente: www.example.com → 192.168.200.10 (acesso direto via rede local)
  • Externamente: www.example.com → 203.0.113.10 (acesso via Internet)

Isso otimiza o tráfego, evitando que usuários internos saiam para a Internet e voltem para acessar um servidor local.

2. Serviços Exclusivamente Internos

Alguns serviços devem ser acessíveis apenas internamente, como servidores de banco de dados, sistemas de gerenciamento interno, etc.:

  • Internamente: db.example.com → 192.168.200.30
  • Externamente: db.example.com → NXDOMAIN (domínio inexistente)

Isso aumenta a segurança ao ocultar completamente serviços internos de consultas externas.

3. Ambientes de Desenvolvimento e Teste

Organizações com ambientes de desenvolvimento, teste e produção podem usar Split-Horizon para direcionar usuários para o ambiente apropriado:

  • Desenvolvedores: api.example.com → servidor de desenvolvimento
  • Testadores: api.example.com → servidor de teste
  • Usuários externos: api.example.com → servidor de produção

4. Filiais e Escritórios Remotos

Empresas com múltiplas filiais podem implementar views específicas para cada localidade:

  • Filial A: intranet.example.com → servidor local da Filial A
  • Filial B: intranet.example.com → servidor local da Filial B
  • Sede: intranet.example.com → servidor central da Sede

Planejamento para Implementação de Views

Antes de começar a configuração, é essencial planejar cuidadosamente a implementação de views. Um bom planejamento evita problemas futuros e facilita a manutenção.

Identificação de Redes e Clientes

Primeiro, identifique as diferentes redes e grupos de clientes que precisarão de views específicas:

  1. Redes Internas: LANs, VPNs, redes de gerenciamento
  2. Redes DMZ: Servidores expostos parcialmente
  3. Redes Externas: Internet e parceiros externos
  4. Redes Especiais: Ambientes de desenvolvimento, teste, etc.

Definição de ACLs

Para cada grupo de clientes, defina ACLs (Access Control Lists) que serão usadas para identificá-los:

1
2
3
4
5
6
7
8
9
10
11
12
13

acl "internal_networks" {
    localhost;
    192.168.0.0/16;    // Redes corporativas
    10.0.0.0/8;        // Redes VPN
};

acl "dmz_networks" {
    172.16.0.0/24;     // Rede DMZ
};

acl "external_networks" {
    any;               // Qualquer endereço não correspondente às ACLs anteriores
};

Planejamento de Zonas

Para cada view, determine quais zonas serão incluídas e como serão configuradas:

  1. View Interna:
    • Zonas diretas com endereços IP privados
    • Zonas reversas para redes internas
    • Zonas para serviços exclusivamente internos
  2. View DMZ:
    • Zonas diretas com mix de endereços privados e públicos
    • Zonas reversas para a rede DMZ
    • Acesso limitado a serviços internos
  3. View Externa:
    • Zonas diretas apenas com endereços IP públicos
    • Zonas reversas para endereços IP públicos
    • Sem acesso a serviços exclusivamente internos

Considerações de Segurança

Planeje aspectos de segurança como:

  • Quais views terão recursão habilitada
  • Quais views permitirão transferências de zona
  • Como serão implementadas atualizações dinâmicas em cada view
  • Se DNSSEC será implementado e como será gerenciado em diferentes views

Configuração Básica de Views no BIND

Agora que temos um plano, vamos implementar a configuração básica de views no BIND.

Estrutura do Arquivo named.conf com Views

A estrutura básica do arquivo named.conf com views é a seguinte:

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

// ACLs globais
acl "internal_networks" { ... };
acl "dmz_networks" { ... };

// Opções globais (aplicadas a todas as views)
options {
    directory "/var/named";
    // Outras opções globais
};

// View interna
view "internal" {
    match-clients { internal_networks; };
    
    // Opções específicas da view interna
    recursion yes;
    
    // Zonas da view interna
    zone "example.com" { ... };
    zone "168.192.in-addr.arpa" { ... };
};

// View DMZ
view "dmz" {
    match-clients { dmz_networks; };
    
    // Opções específicas da view DMZ
    recursion yes;
    
    // Zonas da view DMZ
    zone "example.com" { ... };
    zone "16.172.in-addr.arpa" { ... };
};

// View externa
view "external" {
    match-clients { any; };
    
    // Opções específicas da view externa
    recursion no;
    
    // Zonas da view externa
    zone "example.com" { ... };
    zone "113.0.203.in-addr.arpa" { ... };
};

Diretiva match-clients

A diretiva match-clients é o coração da configuração de views. Ela determina quais clientes correspondem a cada view:

1
2
3
4

view "internal" {
    match-clients { internal_networks; };
    // ...
};

Além de ACLs, você pode usar endereços IP individuais, blocos CIDR, e até mesmo a negação com “!”:

1
2
3
4

view "special" {
    match-clients { 192.168.10.0/24; !192.168.10.100; };
    // ...
};

Ordem das Views

A ordem das views no arquivo de configuração é crucial. O BIND processa as views na ordem em que aparecem, e a primeira view que corresponde aos critérios do cliente é a que será usada.

Por isso, é importante definir as views mais específicas primeiro, e as mais genéricas por último:

  1. Views para redes ou hosts específicos
  2. View para redes internas
  3. View para redes DMZ
  4. View externa (geralmente usando match-clients { any; })

Implementação de DNS Split-Horizon

Vamos implementar um DNS Split-Horizon completo para o domínio example.com, com views interna e externa.

+-----------------+   Consulta www.example.com   +-----------------------+
| Cliente Interno | ---------------------------> | Servidor BIND         |
| (192.168.200.5) |                              | (IP: 192.168.200.49 / |
+-----------------+                              |      203.0.113.49)    |
                                                 +-----------+-----------+
                                                             | match-clients { internal_networks; }
                                                             V
                                                      +-------------+
                                                      | View:       |
                                                      | "internal"  |
                                                      +-------------+
                                                             | Lê /var/named/zones/internal/example.com.zone
                                                             V
                                                      +-------------+
                                                      | Resposta:   |
                                                      | 192.168.200.10 |
                                                      +-------------+
                                                             |
                                                             V
+-----------------+   Consulta www.example.com   +-----------+-----------+
| Cliente Externo | ---------------------------> | Servidor BIND         |
| (8.8.8.8)       |                              | (IP: 192.168.200.49 / |
+-----------------+                              |      203.0.113.49)    |
                                                 +-----------+-----------+
                                                             | match-clients { any; } (Não correspondeu a "internal")
                                                             V
                                                      +-------------+
                                                      | View:       |
                                                      | "external"  |
                                                      +-------------+
                                                             | Lê /var/named/zones/external/example.com.zone
                                                             V
                                                      +-------------+
                                                      | Resposta:   |
                                                      | 203.0.113.10 |
                                                      +-------------+

Figura 1: Diagrama detalhado de DNS Split-Horizon com Views

Estrutura de Diretórios

Primeiro, vamos garantir que temos a estrutura de diretórios adequada:

1
2
3
4
5
6

sudo mkdir -p /var/named/zones/internal
sudo mkdir -p /var/named/zones/external

sudo chown -R root:named /var/named/zones
sudo chmod -R 750 /var/named/zones
sudo restorecon -Rv /var/named/zones

Configuração do named.conf

Agora, vamos editar o arquivo /etc/named.conf:

1

sudo vi /etc/named.conf

Substitua o conteúdo por:

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185

// named.conf for BIND DNS Server on Oracle Linux 9
// Configuration with Split-Horizon DNS

// ================================================================================
// ACLs - Access Control Lists
// ================================================================================
acl "internal_networks" {
    localhost;
    192.168.200.0/24;    // Rede principal
    10.10.0.0/16;        // Rede VPN
};

acl "dns_servers" {
    192.168.200.49;      // Este servidor (primário)
    192.168.200.50;      // Servidor secundário
};

// ================================================================================
// Options
// ================================================================================
options {
    // Directory for relative paths
    directory "/var/named";
    
    // Listen on specific interfaces and ports
    listen-on port 53 { 
        127.0.0.1;
        192.168.200.49;    // IP interno
        203.0.113.49;      // IP público
    };
    listen-on-v6 port 53 { ::1; };
    
    // Files for statistics, dump and dynamic managed keys
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    secroots-file "/var/named/data/named.secroots";
    recursing-file "/var/named/data/named.recursing";
    
    // Hide version to prevent reconnaissance
    version none;
    hostname none;
    server-id none;
    
    // DNSSEC configuration
    dnssec-validation auto;
    
    // Directory for dynamic managed keys
    managed-keys-directory "/var/named/dynamic";
    
    // PID and session key files
    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
    
    // Include crypto policies
    include "/etc/crypto-policies/back-ends/bind.config";
};

// ================================================================================
// Logging Configuration
// ================================================================================
logging {
    channel default_debug {
        file "data/named.run";
        severity dynamic;
    };
    
    channel general_log {
        file "/var/log/named/general.log" versions 3 size 5m;
        severity info;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    
    channel security_log {
        file "/var/log/named/security.log" versions 3 size 5m;
        severity info;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    
    channel query_log {
        file "/var/log/named/query.log" versions 3 size 10m;
        severity info;
        print-time yes;
    };
    
    category default { general_log; };
    category general { general_log; };
    category security { security_log; };
    category queries { query_log; };
};

// ================================================================================
// View for Internal Networks
// ================================================================================
view "internal" {
    match-clients { internal_networks; };
    
    // Access control for internal view
    allow-query { internal_networks; };
    allow-transfer { dns_servers; };
    allow-update { none; };
    
    // Recursion settings
    recursion yes;
    allow-recursion { internal_networks; };
    
    // Forward zone for example.com (internal view)
    zone "example.com" IN {
        type master;
        file "zones/internal/example.com.zone";
        allow-transfer { dns_servers; };
        allow-update { none; };
    };
    
    // Reverse zone for 192.168.200.0/24 (internal network)
    zone "200.168.192.in-addr.arpa" IN {
        type master;
        file "zones/internal/200.168.192.in-addr.arpa.zone";
        allow-transfer { dns_servers; };
        allow-update { none; };
    };
    
    // Reverse zone for 10.10.0.0/16 (VPN network)
    zone "10.10.in-addr.arpa" IN {
        type master;
        file "zones/internal/10.10.in-addr.arpa.zone";
        allow-transfer { dns_servers; };
        allow-update { none; };
    };
    
    // Include standard zones
    include "/etc/named.rfc1912.zones";
    
    // Root hints zone
    zone "." IN {
        type hint;
        file "named.ca";
    };
    
    // Include DNSSEC root key
    include "/etc/named.root.key";
};

// ================================================================================
// View for External Networks
// ================================================================================
view "external" {
    match-clients { any; };
    
    // Access control for external view
    allow-query { any; };
    allow-transfer { dns_servers; };
    allow-update { none; };
    
    // Recursion settings (disabled for external clients)
    recursion no;
    
    // Forward zone for example.com (external view)
    zone "example.com" IN {
        type master;
        file "zones/external/example.com.zone";
        allow-transfer { dns_servers; };
        allow-update { none; };
    };
    
    // Reverse zone for 203.0.113.0/24 (public IP range)
    zone "113.0.203.in-addr.arpa" IN {
        type master;
        file "zones/external/113.0.203.in-addr.arpa.zone";
        allow-transfer { dns_servers; };
        allow-update { none; };
    };
    
    // Root hints zone
    zone "." IN {
        type hint;
        file "named.ca";
    };
    
    // Include DNSSEC root key
    include "/etc/named.root.key";
};

Explicação da Configuração

Vamos analisar os principais elementos desta configuração:

ACLs

1
2
3
4
5

acl "internal_networks" {
    localhost;
    192.168.200.0/24;    // Rede principal
    10.10.0.0/16;        // Rede VPN
};

Esta ACL define quais redes são consideradas internas. Consultas dessas redes serão respondidas pela view “internal”.

View Interna

1
2
3
4
5
6
7
8
9
10
11
12
13
14

view "internal" {
    match-clients { internal_networks; };
    
    // Access control for internal view
    allow-query { internal_networks; };
    allow-transfer { dns_servers; };
    allow-update { none; };
    
    // Recursion settings
    recursion yes;
    allow-recursion { internal_networks; };
    
    // Zonas...
};

Esta view:

  • Corresponde a clientes das redes internas
  • Permite consultas apenas de redes internas
  • Permite transferências de zona apenas para servidores DNS específicos
  • Habilita recursão para clientes internos

View Externa

1
2
3
4
5
6
7
8
9
10
11
12
13

view "external" {
    match-clients { any; };
    
    // Access control for external view
    allow-query { any; };
    allow-transfer { dns_servers; };
    allow-update { none; };
    
    // Recursion settings (disabled for external clients)
    recursion no;
    
    // Zonas...
};

Esta view:

  • Corresponde a qualquer cliente que não corresponda a views anteriores
  • Permite consultas de qualquer origem
  • Permite transferências de zona apenas para servidores DNS específicos
  • Desabilita recursão para clientes externos (importante para segurança)

Criação dos Arquivos de Zona para a View Interna

Agora, vamos criar os arquivos de zona para a view interna.

Zona Direta (example.com) - View Interna

1

sudo vi /var/named/zones/internal/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
51
52
53
54
55
56
57

; Zone file for example.com - INTERNAL VIEW
$TTL 86400      ; 1 day default TTL
$ORIGIN example.com.

; SOA Record
@       IN SOA  ns1.example.com. admin.example.com. (
                    2025052001  ; 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

; A Records for Internal Services
intranet    IN A    192.168.200.15
db          IN A    192.168.200.30
ldap        IN A    192.168.200.31
kdc         IN A    192.168.200.32
monitor     IN A    192.168.200.40

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

Zona Reversa (192.168.200.0/24) - View Interna

1

sudo vi /var/named/zones/internal/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
25
26
27
28
29

; Reverse zone file for 192.168.200.0/24 - INTERNAL VIEW
$TTL 86400      ; 1 day default TTL
$ORIGIN 200.168.192.in-addr.arpa.

; SOA Record
@       IN SOA  ns1.example.com. admin.example.com. (
                    2025052001  ; 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.
15      IN PTR  intranet.example.com.
20      IN PTR  mail.example.com.
21      IN PTR  mail2.example.com.
30      IN PTR  db.example.com.
31      IN PTR  ldap.example.com.
32      IN PTR  kdc.example.com.
40      IN PTR  monitor.example.com.
49      IN PTR  ns1.example.com.
50      IN PTR  ns2.example.com.

Zona Reversa (10.10.0.0/16) - View Interna

1

sudo vi /var/named/zones/internal/10.10.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

; Reverse zone file for 10.10.0.0/16 - INTERNAL VIEW
$TTL 86400      ; 1 day default TTL
$ORIGIN 10.10.in-addr.arpa.

; SOA Record
@       IN SOA  ns1.example.com. admin.example.com. (
                    2025052001  ; 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 for VPN clients
1.0     IN PTR  vpn-client1.example.com.
2.0     IN PTR  vpn-client2.example.com.
3.0     IN PTR  vpn-client3.example.com.

Criação dos Arquivos de Zona para a View Externa

Agora, vamos criar os arquivos de zona para a view externa.

Zona Direta (example.com) - View Externa

1

sudo vi /var/named/zones/external/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

; Zone file for example.com - EXTERNAL VIEW
$TTL 86400      ; 1 day default TTL
$ORIGIN example.com.

; SOA Record
@       IN SOA  ns1.example.com. admin.example.com. (
                    2025052001  ; 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    203.0.113.49
ns2     IN A    203.0.113.50

; A Records for Mail Servers
mail    IN A    203.0.113.20
mail2   IN A    203.0.113.21

; A Records for Web Servers
www     IN A    203.0.113.10
        IN A    203.0.113.11  ; Round-robin DNS for load balancing

; AAAA Records (IPv6)
ns1     IN AAAA 2001:db8:1::49
ns2     IN AAAA 2001:db8:1::50
www     IN AAAA 2001:db8:1::10
mail    IN AAAA 2001:db8:1::20

; CNAME Records
ftp     IN CNAME www
webmail IN CNAME mail

; TXT Records
@       IN TXT  "v=spf1 mx ip4:203.0.113.0/24 -all"
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Note que esta zona contém apenas serviços que devem ser acessíveis externamente, e todos os endereços IP são públicos.

Zona Reversa (203.0.113.0/24) - View Externa

1

sudo vi /var/named/zones/external/113.0.203.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 203.0.113.0/24 - EXTERNAL VIEW
$TTL 86400      ; 1 day default TTL
$ORIGIN 113.0.203.in-addr.arpa.

; SOA Record
@       IN SOA  ns1.example.com. admin.example.com. (
                    2025052001  ; 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.

Definição de Permissões e Contexto SELinux

Defina as permissões e o contexto SELinux corretos para todos os arquivos de zona:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

sudo chown root:named /var/named/zones/internal/example.com.zone
sudo chown root:named /var/named/zones/internal/200.168.192.in-addr.arpa.zone
sudo chown root:named /var/named/zones/internal/10.10.in-addr.arpa.zone
sudo chown root:named /var/named/zones/external/example.com.zone
sudo chown root:named /var/named/zones/external/113.0.203.in-addr.arpa.zone

sudo chmod 640 /var/named/zones/internal/example.com.zone
sudo chmod 640 /var/named/zones/internal/200.168.192.in-addr.arpa.zone
sudo chmod 640 /var/named/zones/internal/10.10.in-addr.arpa.zone
sudo chmod 640 /var/named/zones/external/example.com.zone
sudo chmod 640 /var/named/zones/external/113.0.203.in-addr.arpa.zone

sudo restorecon -v /var/named/zones/internal/example.com.zone
sudo restorecon -v /var/named/zones/internal/200.168.192.in-addr.arpa.zone
sudo restorecon -v /var/named/zones/internal/10.10.in-addr.arpa.zone
sudo restorecon -v /var/named/zones/external/example.com.zone
sudo restorecon -v /var/named/zones/external/113.0.203.in-addr.arpa.zone

Verificação da Sintaxe

Antes de recarregar o servidor DNS, verifique a sintaxe da configuração e dos arquivos de zona:

1
2
3
4
5
6

sudo named-checkconf
sudo named-checkzone example.com /var/named/zones/internal/example.com.zone
sudo named-checkzone example.com /var/named/zones/external/example.com.zone
sudo named-checkzone 200.168.192.in-addr.arpa /var/named/zones/internal/200.168.192.in-addr.arpa.zone
sudo named-checkzone 10.10.in-addr.arpa /var/named/zones/internal/10.10.in-addr.arpa.zone
sudo named-checkzone 113.0.203.in-addr.arpa /var/named/zones/external/113.0.203.in-addr.arpa.zone

Recarregando o Servidor DNS

Após verificar a sintaxe, recarregue o servidor DNS:

1

sudo rndc reload

Ou, se preferir reiniciar o serviço:

1

sudo systemctl restart named

Testes e Validação de Views

Agora que configuramos o DNS Split-Horizon, precisamos testar se as views estão funcionando corretamente.

Teste da View Interna

Para testar a view interna, execute consultas a partir de um host na rede interna:

1
2
3
4
5
6
7
8

# Teste de resolução direta
dig @192.168.200.49 www.example.com

# Teste de resolução reversa
dig @192.168.200.49 -x 192.168.200.10

# Teste de serviço interno
dig @192.168.200.49 intranet.example.com

Você deve receber respostas com endereços IP internos (192.168.200.x).

Teste da View Externa

Para testar a view externa, você pode:

  1. Executar consultas a partir de um host na Internet
  2. Simular consultas externas usando o endereço IP público do servidor
  3. Usar a opção -b do dig para simular consultas de um endereço IP externo
1
2
3
4
5

# Simular consulta externa especificando o endereço IP público
dig @203.0.113.49 www.example.com

# Simular consulta externa usando a opção -b
dig @192.168.200.49 -b 8.8.8.8 www.example.com

Você deve receber respostas com endereços IP públicos (203.0.113.x).

Teste de Serviços Exclusivamente Internos

Verifique se serviços exclusivamente internos não são expostos externamente:

1
2
3
4
5

# Consulta interna (deve retornar um endereço IP)
dig @192.168.200.49 db.example.com

# Consulta externa (deve retornar NXDOMAIN)
dig @192.168.200.49 -b 8.8.8.8 db.example.com

Teste de Recursão

Verifique se a recursão está habilitada apenas para clientes internos:

1
2
3
4
5

# Consulta interna (deve resolver domínios externos)
dig @192.168.200.49 google.com

# Consulta externa (deve falhar ou retornar REFUSED)
dig @192.168.200.49 -b 8.8.8.8 google.com

Configurações Avançadas de Views

Agora que temos uma configuração básica de DNS Split-Horizon funcionando, vamos explorar algumas configurações avançadas.

Views Baseadas em Outros Critérios

Além de endereços IP, as views podem ser baseadas em outros critérios, como:

Views Baseadas em Porta

1
2
3
4
5

view "special" {
    match-clients { 192.168.200.0/24; };
    match-destinations { 192.168.200.49 port 53; };
    // ...
};

Views Baseadas em TSIG Key

1
2
3
4
5
6
7
8
9

key "example-key" {
    algorithm hmac-sha256;
    secret "your-base64-encoded-secret-key";
};

view "secure" {
    match-clients { key example-key; };
    // ...
};

Configuração de Múltiplas Views

Em ambientes complexos, você pode precisar de mais de duas views. Por exemplo:

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

// View para rede de desenvolvimento
view "development" {
    match-clients { 192.168.10.0/24; };
    // ...
};

// View para rede de teste
view "testing" {
    match-clients { 192.168.20.0/24; };
    // ...
};

// View para rede de produção interna
view "production_internal" {
    match-clients { 192.168.30.0/24; };
    // ...
};

// View para DMZ
view "dmz" {
    match-clients { 172.16.0.0/24; };
    // ...
};

// View externa
view "external" {
    match-clients { any; };
    // ...
};

Compartilhamento de Zonas entre Views

Em alguns casos, você pode querer compartilhar zonas entre views. Isso pode ser feito usando a opção in-view:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

view "internal" {
    match-clients { internal_networks; };
    
    zone "example.com" IN {
        type master;
        file "zones/internal/example.com.zone";
    };
    
    zone "shared.example.com" IN {
        in-view "shared";
    };
};

view "shared" {
    match-clients { none; };  // Esta view não corresponde diretamente a nenhum cliente
    
    zone "shared.example.com" IN {
        type master;
        file "zones/shared/shared.example.com.zone";
    };
};

Configuração de Response Policy Zones (RPZ) em Views

As Response Policy Zones (RPZ) permitem implementar políticas de resposta DNS, como bloqueio de domínios maliciosos. Você pode configurar RPZs diferentes para cada view:

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

view "internal" {
    match-clients { internal_networks; };
    
    // RPZ para clientes internos
    response-policy {
        zone "rpz.internal";
    };
    
    zone "rpz.internal" IN {
        type master;
        file "zones/rpz/internal.rpz";
        allow-query { none; };
    };
    
    // ... outras zonas ...
};

view "external" {
    match-clients { any; };
    
    // RPZ para clientes externos
    response-policy {
        zone "rpz.external";
    };
    
    zone "rpz.external" IN {
        type master;
        file "zones/rpz/external.rpz";
        allow-query { none; };
    };
    
    // ... outras zonas ...
};

Considerações sobre DNSSEC com Views

A implementação de DNSSEC em um ambiente com views requer considerações especiais, pois as assinaturas DNSSEC são específicas para cada conjunto de registros.

Desafios do DNSSEC com Views

Quando você tem views diferentes com conteúdo diferente para o mesmo domínio, surgem alguns desafios:

  1. Assinaturas Diferentes: Cada view terá assinaturas DNSSEC diferentes para o mesmo domínio
  2. Chaves Diferentes: Você pode precisar de conjuntos de chaves diferentes para cada view
  3. Delegação: A zona pai precisa ter os registros DS corretos, mas só pode ter um conjunto

Estratégias para DNSSEC com Views

Existem algumas estratégias para implementar DNSSEC com views:

1. DNSSEC Apenas na View Externa

A abordagem mais comum é implementar DNSSEC apenas na view externa, mantendo a view interna sem DNSSEC:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

view "internal" {
    match-clients { internal_networks; };
    
    // Desabilitar validação DNSSEC para clientes internos
    dnssec-validation no;
    
    // ... zonas ...
};

view "external" {
    match-clients { any; };
    
    // Habilitar validação DNSSEC para clientes externos
    dnssec-validation auto;
    
    // ... zonas ...
};

2. DNSSEC em Todas as Views com Chaves Separadas

Outra abordagem é implementar DNSSEC em todas as views, mas com conjuntos de chaves separados:

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

view "internal" {
    match-clients { internal_networks; };
    
    // Habilitar validação DNSSEC
    dnssec-validation auto;
    
    // Zona com DNSSEC
    zone "example.com" IN {
        type master;
        file "zones/internal/example.com.signed";
        key-directory "keys/internal";
        auto-dnssec maintain;
        inline-signing yes;
    };
};

view "external" {
    match-clients { any; };
    
    // Habilitar validação DNSSEC
    dnssec-validation auto;
    
    // Zona com DNSSEC
    zone "example.com" IN {
        type master;
        file "zones/external/example.com.signed";
        key-directory "keys/external";
        auto-dnssec maintain;
        inline-signing yes;
    };
};

Esta abordagem requer gerenciamento cuidadoso das chaves e registros DS.

Troubleshooting de Views

Mesmo com uma configuração cuidadosa, problemas podem surgir. Aqui estão algumas situações comuns e como resolvê-las:

Problema: View Incorreta Sendo Selecionada

Verificação:

1

dig @192.168.200.49 www.example.com

Se você receber uma resposta inesperada (por exemplo, um endereço IP público quando deveria receber um endereço IP privado), a view incorreta pode estar sendo selecionada.

Possíveis soluções:

  1. Verifique a ordem das views no named.conf (lembre-se que a primeira view correspondente é usada)
  2. Verifique as ACLs match-clients para garantir que estão corretas
  3. Use a opção +subnet do dig para testar consultas de diferentes redes:
    1

    dig @192.168.200.49 www.example.com +subnet=192.168.200.0/24

Problema: Zonas Não Carregam em Views Específicas

Verificação:

1

sudo rndc zonestatus example.com in internal

Possíveis soluções:

  1. Verifique a sintaxe da definição da zona na view
  2. Verifique permissões e contexto SELinux dos arquivos de zona
  3. Verifique logs: sudo tail -f /var/log/named/general.log

Problema: Recursão Não Funciona em Uma View

Verificação:

1

dig @192.168.200.49 google.com

Possíveis soluções:

  1. Verifique se recursion está definido como yes na view
  2. Verifique allow-recursion na view
  3. Verifique se o servidor tem conectividade com a Internet

Problema: Transferência de Zona Falha entre Views

Verificação:

1

dig @primary_server example.com AXFR

Possíveis soluções:

  1. Verifique allow-transfer na definição da zona na view
  2. Verifique se o servidor secundário está na ACL correta
  3. Verifique logs em ambos os servidores

Melhores Práticas para Views e DNS Split-Horizon

Para finalizar, aqui estão algumas melhores práticas para implementação de views e DNS Split-Horizon:

1. Planejamento e Documentação

  • Documente claramente quais redes correspondem a quais views
  • Mantenha um registro de quais serviços estão disponíveis em cada view
  • Documente as diferenças entre as zonas nas diferentes views

2. Organização de Arquivos

  • Use uma estrutura de diretórios clara para separar arquivos de zona de diferentes views
  • Use nomes de arquivo consistentes e descritivos
  • Mantenha os números de serial sincronizados entre as diferentes versões da mesma zona

3. Segurança

  • Desabilite recursão para clientes externos
  • Implemente rate limiting para prevenir ataques de amplificação
  • Considere usar TSIG para transferências de zona entre servidores
  • Oculte informações sensíveis da view externa

4. Manutenção

  • Automatize a atualização de zonas para garantir consistência entre views
  • Implemente monitoramento para detectar discrepâncias entre views
  • Teste regularmente a resolução de nomes em todas as views

5. Desempenho

  • Considere a carga adicional que múltiplas views podem impor ao servidor
  • Monitore o uso de recursos e ajuste conforme necessário
  • Em ambientes de alto tráfego, considere servidores dedicados para diferentes views

Conclusão e Próximos Passos

Neste quarto artigo da série, exploramos o poderoso recurso de views do BIND e implementamos um DNS Split-Horizon completo. Configuramos views internas e externas, criamos zonas específicas para cada view e aprendemos a testar e validar a configuração.

As views são uma ferramenta poderosa que permite apresentar diferentes respostas DNS dependendo da origem da consulta, aumentando a segurança, otimizando o tráfego e proporcionando flexibilidade operacional.

O que vem a seguir?

No próximo artigo, “Segurança e Hardening de Servidores DNS BIND no Oracle Linux 9”, abordaremos:

  • Configuração de permissões de arquivos e diretórios
  • Implementação e configuração do SELinux para BIND
  • Configuração de TSIG para transferências de zona seguras
  • Implementação de DNSSEC
  • Melhores práticas de segurança para servidores DNS

Não perca! Nossa jornada para dominar o DNS BIND no Oracle Linux 9 continua.

Referências e Recursos Adicionais

Servidores, DNS, Linux
BIND DNS Oracle Linux
This post is licensed under CC BY 4.0 by the author.