Post

DNS com o BIND Parte 6: TSIG - Transferências Seguras de Zona DNS

Posted
By Gean Martins
13 min read
DNS com o BIND Parte 6: TSIG - Transferências Seguras de Zona DNS

Introdução

Até a Parte 5, configuramos transferências de zona entre os servidores primário e secundário. Porém, essas transferências ocorrem sem autenticação criptográfica. Qualquer servidor que conhecer o endereço IP do primário pode solicitar uma transferência de zona completa (AXFR), comprometendo a segurança dos seus dados DNS. Na Parte 6, vamos implementar TSIG (Transaction Signatures), um mecanismo que usa autenticação criptográfica baseada em HMAC para garantir que apenas servidores autorizados possam receber transferências de zona.

O que será visto nesta sexta parte

  • Conceitos de TSIG: O que é, por que usar e quais algoritmos são suportados.
  • Geração de Chaves: Como criar chaves TSIG seguras com tsig-keygen.
  • Configuração em NS1 (Primário): Incluir chaves e definir permissões de transferência baseadas em TSIG.
  • Configuração em NS2 (Secundário): Usar as mesmas chaves para autenticar transferências.
  • Testes e Validação: Verificar se as transferências com TSIG funcionam corretamente.
  • Boas Práticas: Rotação de chaves, backup e auditoria.

Pré-requisitos

  • Ter completado com sucesso a Parte 5, com servidores primário e secundário configurados.
  • Compreender conceitos básicos de criptografia e autenticação.

1. Conceitos Fundamentais de TSIG

1.1 O que é TSIG?

TSIG (Transaction Signatures), definido na RFC 2845, é um mecanismo que adiciona uma assinatura criptográfica a mensagens DNS. Essa assinatura é calculada usando um segredo compartilhado (chave) entre o cliente e o servidor, garantindo que:

  1. Autenticidade: Apenas quem possui a chave secreta pode gerar uma assinatura válida.
  2. Integridade: A mensagem não foi alterada durante a transmissão.
  3. Não-repúdio: O servidor que enviou a mensagem não pode negar que a enviou.

1.2 Por que Usar TSIG?

Sem TSIG, qualquer servidor que conhecer o endereço IP do seu primário pode solicitar uma transferência de zona completa (AXFR). Isso representa um risco de segurança significativo, pois:

  • Exposição de Dados: Um atacante pode obter uma cópia de todas as suas zonas DNS.
  • Reconhecimento: Um atacante pode mapear toda a sua infraestrutura DNS.
  • Ataques Subsequentes: Com a lista completa de hosts, um atacante pode planejar ataques mais direcionados.

Com TSIG, apenas servidores que possuem a chave secreta correta podem receber transferências de zona, reduzindo drasticamente o risco.

1.3 Algoritmos Suportados

O BIND suporta vários algoritmos HMAC para gerar as assinaturas:

AlgoritmoForçaRecomendação
HMAC-MD5FracaNão recomendado (MD5 está deprecado)
HMAC-SHA1ModeradaAceitável, mas SHA256 é preferível
HMAC-SHA256ForteRecomendado (padrão)
HMAC-SHA512Muito ForteRecomendado para ambientes críticos

Recomendação: Use HMAC-SHA256 como padrão. É suficientemente seguro, amplamente suportado e oferece um bom equilíbrio entre segurança e desempenho.

2. Geração de Chaves TSIG

2.1 Usando tsig-keygen

O comando tsig-keygen gera uma chave TSIG aleatória e segura, codificada em base64.

Em NS1 (primário), gere as chaves:

1
2
3
4
5

# Chave para transferências internas
tsig-keygen -a HMAC-SHA256 internals_transfers > /tmp/internals_transfers.key

# Chave para transferências externas
tsig-keygen -a HMAC-SHA256 externals_transfers > /tmp/externals_transfers.key

Verifique o conteúdo das chaves geradas:

1
2
3
4
5

[gean@ns1 ~]$ cat /tmp/internals_transfers.key
key "internals_transfers" {
    algorithm hmac-sha256;
    secret "7mtxqXsGstZ1HZUnS2UM+t3p9dr4r6gNwPMjVxm11tY=";
};

2.2 Copiar Chaves para o Diretório Seguro

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

# Copiar chaves para o diretório de configuração
sudo cp /tmp/internals_transfers.key /etc/named/keys/
sudo cp /tmp/externals_transfers.key /etc/named/keys/

# Definir permissões apropriadas
sudo chown root:named /etc/named/keys -R
sudo find /etc/named/keys -type f -exec chmod 640 {} \;

# Verificar permissões
[gean@ns1 ~]$ sudo ls -l /etc/named/keys
total 8
-rw-r-----. 1 root named 111 Feb  7 12:50 externals_transfers.key
-rw-r-----. 1 root named 111 Feb  7 12:50 internals_transfers.key

2.3 Transferir Chaves para NS2 (Secundário)

Transfira as chaves de forma segura para o servidor secundário. Use scp com autenticação SSH:

1
2
3

# De NS1, copiar chaves para NS2
scp /tmp/internals_transfers.key gean@10.16.32.3:/tmp/
scp /tmp/externals_transfers.key gean@10.16.32.3:/tmp/

Em NS2, receba e configure as chaves:

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

# Mover chaves para o diretório seguro
sudo mv /tmp/internals_transfers.key /etc/named/keys/
sudo mv /tmp/externals_transfers.key /etc/named/keys/

# Definir permissões
sudo chown root:named /etc/named/keys -R
sudo find /etc/named/keys -type f -exec chmod 640 {} \;

# Aplicar contexto SELinux
sudo semanage fcontext -a -t named_conf_t "/etc/named/keys(/.*)?"
sudo restorecon -Rv /etc/named/keys

# Verificar
[gean@ns2 ~]$ sudo ls -lZ /etc/named/keys
total 8
-rw-r-----. 1 root named unconfined_u:object_r:named_conf_t:s0 111 Feb  7 13:15 externals_transfers.key
-rw-r-----. 1 root named unconfined_u:object_r:named_conf_t:s0 111 Feb  7 13:14 internals_transfers.key

Nota de Segurança: As chaves TSIG são essencialmente senhas. Nunca as transmita em texto plano por canais inseguros. Use SSH, SFTP ou outro protocolo criptografado. Após transferir, delete os arquivos temporários em ambos os servidores com rm /tmp/*.key.

3. Configuração de TSIG em NS1 (Primário)

3.1 Incluir Chaves no /etc/named.conf

Edite /etc/named.conf em NS1 para incluir as chaves nas respectivas 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
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

# /etc/named.conf (em NS1)

// ================================================================================
// ACLs
// ================================================================================
acl "iface_v4" {
    127.0.0.1/32;
    10.16.32.2/32;
    203.0.113.2/32;
};

acl "iface_v6" {
    ::1/128;
    fd00:0:0:1::2/128;
    2001:db8::2/128;
};

acl "internals" {
    ::1/128;
    127.0.0.1/32;
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
    fd00::/48;
};

// ================================================================================
// Opções Globais
// ================================================================================
options {
    listen-on port 53 { iface_v4; };
    listen-on-v6 port 53 { iface_v6; };
    directory "/var/named";
    // ... (outras opções conforme Parte 2)
};

// ================================================================================
// Logging
// ================================================================================
include "/etc/named/named.logging.conf";

// ================================================================================
// Views
// ================================================================================
view "internals"
{
    match-clients { internals; };
    allow-query { internals; };
    allow-recursion { internals; };
    allow-query-cache { internals; };
    
    // Incluir chave TSIG para a view interna
    include "/etc/named/keys/internals_transfers.key";
    
    // Definir servidor remoto com TSIG
    server 10.16.32.3 {
        keys { internals_transfers; };
    };
    
    server fd00:0:0:1::3 {
        keys { internals_transfers; };
    };
    
    // Permitir transferência apenas com TSIG
    allow-transfer { key internals_transfers; };
    also-notify { 10.16.32.3; fd00:0:0:1::3; };

    include "/etc/named/named.common.zones";
    include "/etc/named/named.internals.zones";
};

view "externals"
{
    match-clients { any; };
    recursion no;
    
    // Incluir chave TSIG para a view externa
    include "/etc/named/keys/externals_transfers.key";
    
    // Definir servidor remoto com TSIG
    server 203.0.113.3 {
        keys { externals_transfers; };
    };
    
    server 2001:db8::3 {
        keys { externals_transfers; };
    };
    
    // Permitir transferência apenas com TSIG
    allow-transfer { key externals_transfers; };
    also-notify { 203.0.113.3; 2001:db8::3; };

    include "/etc/named/named.externals.zones";
};

3.2 Validar e Recarregar

1
2
3
4
5
6
7
8

# Validar a configuração
sudo named-checkconf /etc/named.conf

# Recarregar o BIND
sudo rndc reload

# Verificar status
sudo systemctl status named

4. Configuração de TSIG em NS2 (Secundário)

4.1 Incluir Chaves no /etc/named.conf

Edite /etc/named.conf em NS2 para incluir as mesmas chaves:

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

# /etc/named.conf (em NS2)

// ================================================================================
// Views
// ================================================================================
view "internals"
{
    match-clients { internals; };
    allow-query { internals; };
    allow-recursion { internals; };
    allow-query-cache { internals; };
    
    // Incluir chave TSIG para a view interna
    include "/etc/named/keys/internals_transfers.key";
    
    // Definir servidor primário com TSIG
    server 10.16.32.2 {
        keys { internals_transfers; };
    };
    
    server fd00:0:0:1::2 {
        keys { internals_transfers; };
    };

    include "/etc/named/named.common.zones";
    include "/etc/named/named.internals.zones";
};

view "externals"
{
    match-clients { any; };
    recursion no;
    
    // Incluir chave TSIG para a view externa
    include "/etc/named/keys/externals_transfers.key";
    
    // Definir servidor primário com TSIG
    server 203.0.113.2 {
        keys { externals_transfers; };
    };
    
    server 2001:db8::2 {
        keys { externals_transfers; };
    };

    include "/etc/named/named.externals.zones";
};

4.2 Validar e Recarregar

1
2
3
4
5
6
7
8

# Validar a configuração
sudo named-checkconf /etc/named.conf

# Recarregar o BIND
sudo rndc reload

# Verificar status
sudo systemctl status named

5. Testes e Validação

5.1 Verificar Transferência com TSIG

Teste a transferência de zona usando TSIG diretamente com dig:

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

# Teste de transferência AXFR com TSIG
[gean@ns2 ~]$ dig @10.16.32.2 -y hmac-sha256:internals_transfers:"7mtxqXsGstZ1HZUnS2UM+t3p9dr4r6gNwPMjVxm11tY=" lab4it.com.br AXFR

; <<>> DiG 9.16.23-RH <<>> @10.16.32.2 -y hmac-sha256:internals_transfers lab4it.com.br AXFR
;; global options: +cmd
lab4it.com.br.		86400	IN	SOA	ns1.lab4it.com.br. hostmaster.lab4it.com.br. 2026020402 14400 3600 2419200 300
lab4it.com.br.		86400	IN	NS	ns1.lab4it.com.br.
lab4it.com.br.		86400	IN	NS	ns2.lab4it.com.br.
ns1.lab4it.com.br.	10800	IN	A	10.16.32.2
ns1.lab4it.com.br.	10800	IN	AAAA	fd00:0:0:1::2
ns2.lab4it.com.br.	10800	IN	A	10.16.32.3
ns2.lab4it.com.br.	10800	IN	AAAA	fd00:0:0:1::3
lab4it.com.br.		86400	IN	SOA	ns1.lab4it.com.br. hostmaster.lab4it.com.br. 2026020402 14400 3600 2419200 300
internals_transfers.	0	ANY	TSIG	hmac-sha256. 1770481388 300 32 Yw5DKd1zR84x2anuou/Qv89+g6o/H+JjiggGLtY7vNU= 63420 NOERROR 0 
;; Query time: 2 msec
;; SERVER: 10.16.32.2#53(10.16.32.2)
;; WHEN: Sat Feb 07 13:23:08 -03 2026
;; XFR size: 14 records (messages 1, bytes 536)

Sucesso! A resposta inclui um registro TSIG no final, indicando que a transferência foi autenticada com sucesso.

5.2 Verificar Logs de Transferência

Monitore os logs em ambos os servidores para confirmar que as transferências com TSIG estão ocorrendo:

1
2
3
4
5

# Em NS1 (primário)
sudo tail -f /var/log/named/xfer.log | grep -i "tsig"

# Em NS2 (secundário)
sudo tail -f /var/log/named/xfer.log | grep -i "tsig"

6. Solucionando Problemas Comuns com TSIG

Sintoma ObservadoProblemaCausa ProvávelSolução
Erro “TSIG mismatch” nos logs.Chaves não correspondem.Chaves diferentes em NS1 e NS2, ou chave corrompida.Regenere as chaves com tsig-keygen e copie novamente para ambos os servidores. Verifique se o conteúdo é idêntico com diff.
Erro “BADKEY” ao tentar transferência.Chave inválida ou corrompida.Arquivo de chave danificado ou permissões incorretas.Regenere a chave com tsig-keygen e reaplique as permissões. Verifique com sudo cat /etc/named/keys/chave.key.
Erro “BADSIG” ao tentar transferência.Assinatura inválida.Relógios dessincronizados entre NS1 e NS2.Sincronize os relógios dos servidores com NTP: sudo ntpdate -s pool.ntp.org ou configure chrony.
Transferência recusada sem erro específico.Chave não está sendo lida.Arquivo de chave não está sendo incluído no named.conf.Verifique se a linha include "/etc/named/keys/chave.key"; está presente na view correta. Use sudo named-checkconf -p para ver a configuração consolidada.
Transferência lenta com TSIG.Overhead de criptografia.Esperado, especialmente com HMAC-SHA512.Considere usar IXFR em vez de AXFR para reduzir a quantidade de dados transferidos.

7. Boas Práticas de Segurança

7.1 Rotação de Chaves

Altere as chaves TSIG periodicamente (recomenda-se anualmente ou quando um administrador deixa a organização):

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

# 1. Gerar nova chave em NS1
tsig-keygen -a HMAC-SHA256 internals_transfers_new > /tmp/internals_transfers_new.key

# 2. Adicionar nova chave ao named.conf em ambos os servidores
# (Mantenha a chave antiga temporariamente para evitar interrupção)
include "/etc/named/keys/internals_transfers_new.key";

# 3. Atualizar a configuração de zonas para usar a nova chave
# (Adicione a nova chave aos blocos `allow-transfer` e `server`)

# 4. Recarregar BIND em ambos os servidores
sudo rndc reload

# 5. Após confirmar que tudo está funcionando, remover a chave antiga
rm /etc/named/keys/internals_transfers.key

7.2 Backup de Chaves

Faça backup seguro das chaves TSIG. Elas são críticas para a operação do seu DNS:

1
2
3
4
5
6
7
8
9

# Backup seguro de chaves
sudo tar -czf /backup/tsig-keys-$(date +%Y%m%d).tar.gz /etc/named/keys/

# Definir permissões restritivas no backup
sudo chmod 600 /backup/tsig-keys-*.tar.gz

# Armazenar em local seguro (idealmente fora do servidor)
# Exemplo: copiar para servidor de backup
scp /backup/tsig-keys-*.tar.gz backup-server:/secure/backup/

7.3 Auditoria de Acesso

Monitore quem tem acesso às chaves e quando elas são usadas:

1
2
3
4
5
6
7
8

# Verificar permissões das chaves
ls -la /etc/named/keys/

# Monitorar transferências com TSIG
tail -f /var/log/named/xfer.log | grep -i "tsig"

# Verificar quem acessou os arquivos de chave
sudo auditctl -w /etc/named/keys/ -p wa -k tsig_keys

8. Configuração Avançada

8.1 TSIG com Múltiplos Secundários

Se você tem vários servidores secundários, pode usar diferentes chaves para cada um:

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

// Em NS1, usar diferentes chaves para diferentes secundários
key "tsig-ns2" {
    algorithm HMAC-SHA256;
    secret "chave_para_ns2";
};

key "tsig-ns3" {
    algorithm HMAC-SHA256;
    secret "chave_para_ns3";
};

server 10.16.32.3 {
    keys { tsig-ns2; };
};

server 10.16.32.4 {
    keys { tsig-ns3; };
};

// Permitir transferência apenas para os secundários autorizados
allow-transfer { key tsig-ns2; key tsig-ns3; };

8.2 TSIG com Parceiros Externos

Se você precisa compartilhar zonas com terceiros (como um ISP ou parceiro), use uma chave TSIG específica:

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

// Para transferências com terceiros
key "tsig-partner-isp" {
    algorithm HMAC-SHA256;
    secret "chave_compartilhada_com_isp";
};

zone "lab4it.com.br" IN {
    type master;
    file "/var/named/zones/externals/forward/lab4it.com.br.zone";
    
    // Permitir transferência apenas para o parceiro
    allow-transfer { key tsig-partner-isp; };
};

9. Fluxo Completo de Transferência com TSIG

O diagrama abaixo ilustra o fluxo completo de uma transferência de zona com autenticação TSIG:

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

NS2 (Secundário)                          NS1 (Primário)
      |                                         |
      |---(1) SOA Query com TSIG?--->|
      |       (Assinado com chave)              |
      |                                         |
      |<--(2) SOA Response com TSIG--|
      |       (Assinado com chave)              |
      |                                         |
      |---(3) AXFR Request com TSIG?--->|
      |       (Assinado com chave)              |
      |                                         |
      |<--(4) AXFR Response com TSIG--|
      |       (Todos os registros)              |
      |       (Assinado com chave)              |
      |                                         |
      | (5) Verifica assinatura TSIG            |
      | (6) Armazena zona em disco              |
      |                                         |

Passos:

  1. NS2 envia uma consulta SOA assinada com TSIG.
  2. NS1 valida a assinatura, confirma que NS2 está autorizado e responde.
  3. NS2 solicita a transferência completa (AXFR), também assinada.
  4. NS1 envia todos os registros da zona, assinados com TSIG.
  5. NS2 valida a assinatura de cada mensagem.
  6. NS2 armazena a zona em disco.

Conclusão

Com TSIG implementado, suas transferências de zona DNS agora estão protegidas por autenticação criptográfica. Apenas servidores que possuem a chave secreta correta podem receber transferências, reduzindo drasticamente o risco de exposição de dados DNS. Esta série de seis partes cobriu os fundamentos essenciais para configurar um servidor DNS BIND robusto, seguro e redundante. Para ambientes de produção, recomenda-se explorar tópicos adicionais como DNSSEC (para assinatura de registros), monitoramento avançado e hardening de segurança.

Próximos Passos

Esta série forneceu uma base sólida para a administração de servidores DNS com BIND. Tópicos avançados como DNSSEC (para validação de integridade de registros), monitoramento e alertas e hardening de segurança são altamente recomendados para implementações de produção. Esperamos que este conhecimento seja útil na sua jornada como administrador de DNS!

Referências

DNS, BIND
DNS BIND TSIG HMAC Segurança
This post is licensed under CC BY 4.0 by the author.