Skip to main content

207.3 Segurança no Servidor DNS


Configurações Gerais​

A segurança em um servidor DNS deve ser extremamente alta, já que podem apontar zonas para endereços que têm o intuito de roubar informações (como o Envenenamento de DNS ou em inglês Poisoning DNS), além de diversos outros tipos de ataques que são feitos em servidores DNS.



Usuário de execução do Bind​

Uma das primeiras etapas é garantir que o servidor DNS não seja executado em cima do usuário Root, por padrão, ele já vem configurado com o usuário named no CentOS e bind no Debian.

# No CentOS:
$ getent passwd named
named:x:25:25:Named:/var/named:/sbin/nologin

$ getent group named
named:x:25:


# No Debian:
$ getent passwd bind
bind:x:112:121::/var/cache/bind:/usr/sbin/nologin

$ getent group bind
bind:x:121:

A opção que determina qual usuário será executado é a opção -u:

$ ps aux | sed -n '1p; /named/p' | grep -v sed
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
bind        4264  0.0  2.5 374092 51192 ?        Ssl  Nov29   0:07 /usr/sbin/named -f -u bind

Essa configuração pode ser alterada em qualquer sistema:

## No Debian:
$ grep -i 'OPTIONS=' /etc/default/named 
OPTIONS="-u bind"


## No CentOS:
$ grep -i 'ExecStart=' /lib/systemd/system/named.service
ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS


Atualização do Bind​

Além disso é sempre bom manter a versão do Bind sempre atualizada, uma boa pedida é sempre compilar para estar sempre com a ultima versão, já que no repositório da distribuição possa demorar um pouco para atualização o pacote.

### Veja como ver a versão do bind:

## No Debian:
$ sudo named -v
BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>

## No CentOS:
$ sudo named -v
BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 (Extended Support Version) <id:7107deb>


Obtenção de informações pelo Cliente​

Os clientes do servidor DNS podem ver qual a versão do Bind está rodando e por padrão o Sistema que está executando ele, veja abaixo:

$ dig @192.168.121.135 chaos version.bind txt +short
"9.16.1-Ubuntu"

$ dig @192.168.121.154 chaos version.bind txt +short
"9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10"

Acontece que isso não é muito bom, então vamos barrar esse tipo de resposta pelo nosso servidor:

## No CentOS:

# Edite o arquivo abaixo:
$ sudo vim /etc/named.conf

## Adicione a opção abaixo:
        version "You have no power here !!";


## No Debian:

# Edite o arquivo abaixo:
$ sudo vim /etc/bind/named.conf.options

## Adicione a opção abaixo (deixei na terceira linha):
        version "You have no power here !!";


## Agora verifique a conf e depois reinicie o serviço:
$ sudo named-checkconf
$ sudo rndc reload

Agora refaça o teste com o dig:

$ dig @192.168.121.135 chaos version.bind txt +short
"You have no power here !!"

$ dig @192.168.121.154 chaos version.bind txt +short
"You have no power here !!"


Blackhole​

Essa configuração faz com que o servidor DNS ignore todas as requisições de um determinado endereço IP.

## No CentOS:

# Edite o arquivo abaixo:
$ sudo vim /etc/named.conf

## Adicione a opção abaixo:
        blackhole { 172.16.1.10; };


## No Debian:

# Edite o arquivo abaixo:
$ sudo vim /etc/bind/named.conf.options

## Adicione a opção abaixo (deixei na terceira linha):
        blackhole { 172.16.1.10; };


## Agora verifique a conf e depois reinicie o serviço:
$ sudo named-checkconf
$ sudo rndc reload


Allow-recursion​

Permite específicar quem pode fazer consultas recursivas no servidor DNS. Mesmo usando essa opção temos que manter o recursion yes;.

## No CentOS:

# Edite o arquivo abaixo:
$ sudo vim /etc/named.conf

## Adicione a opção abaixo:
        allow-recursion { 172.16.1.20; };



## No Debian:

# Edite o arquivo abaixo:
$ sudo vim /etc/bind/named.conf.options

## Adicione a opção abaixo (deixei na terceira linha):
        allow-recursion { 172.16.1.20; };


## Agora verifique a conf e depois reinicie o serviço:
$ sudo named-checkconf
$ sudo rndc reload


Allow-transfer​

Vamos bloquear a transferência de zona para determinados servidores apenas. Essa declaração é geral, ainda existe uma forma de fazer essa declaração mas para zonas específicas.

## No CentOS:

# Edite o arquivo abaixo:
$ sudo vim /etc/named.conf

## Adicione a opção abaixo:
        allow-transfer { 172.16.1.110; };



## No Debian:

# Edite o arquivo abaixo:
$ sudo vim /etc/bind/named.conf.options

## Adicione a opção abaixo (deixei na terceira linha):
        allow-transfer { 172.16.1.110; };


## Agora verifique a conf e depois reinicie o serviço:
$ sudo named-checkconf
$ sudo rndc reload

Para uma zona específica basta usar a mesma opção allow-transfer { 172.16.1.110; };.



ACL​

Podemos criar uma ACL e nela colocar um grupo de IP para aplicar uma regra para a ACL (ai estaremos aplicando a regra para os IP dentro dela).

## No CentOS:

# Edite o arquivo abaixo:
$ sudo vim /etc/named.conf

## Adicione a opção abaixo:
        acl "network-allow" {
                172.16.2.10;
                172.16.2.15;
        };


## No Debian:

# Edite o arquivo abaixo:
$ sudo vim /etc/bind/named.conf.options

## Adicione a opção abaixo (deixei na terceira linha):
        acl "network-allow" {
                172.16.2.10;
                172.16.2.15;
        };

# Depois podemos usar em outras regras como:
        allow-transfer { network-allow; };
        allow-recursion { network-allow; };

## Agora verifique a conf e depois reinicie o serviço:
$ sudo named-checkconf
$ sudo rndc reload


Criação de Views​

Os views são um método de configuração onde um Host ou Rede só pode ver uma parte da configuração, e outro Host ou Rede pode ver outra ou o restante. Aqui nós segmentamos as configurações por grupos de Host ou Rede.


Em qualquer parte da configuração nós temos que adicionar:

view VIEW-NAME {
    match-clients { network-allow; 172.16.3.9; };
    CONFIGURAÇÃO AQUI
};

Exemplo, para configurar nossa zona DNS ubuntu.te somente para uma Rede, podemos fazer assim:

# Edite o arquivo onde está a configuração da Zona e
# deixe assim:

view RedeExterna {
        match-clients { network-allow; 172.16.3.9; };

        zone "ubuntu.te" {
                type master;
                file "/etc/bind/db.ubuntu.te";
        };
};



Bloqueando a resolução de alguns domínios​

Para impedir que o servidor DNS resolva determinados sites, a forma mais adequada no BIND é usar uma Response Policy Zone, também chamada de RPZ. Com a RPZ, o servidor continua funcionando normalmente como resolvedor, mas pode reescrever a resposta para nomes específicos.


Uma política comum é fazer o domínio retornar NXDOMAIN, como se ele não existisse. Primeiro, crie uma zona de política local, por exemplo:

/etc/bind/named.conf.local
zone "bloqueios.rpz" {
        type primary;
        file "/etc/bind/db.bloqueios.rpz";
        allow-query { localhost; };
};

Depois, habilite essa zona dentro das opções do BIND:

/etc/bind/named.conf.options
options {
        response-policy {
                zone "bloqueios.rpz";
        };
};

Agora crie o arquivo da zona RPZ:

/etc/bind/db.bloqueios.rpz
$TTL 1H
@       IN      SOA     localhost. root.localhost. (
                        1       ; serial
                        1h      ; refresh
                        15m     ; retry
                        30d     ; expire
                        2h )    ; minimum

        IN      NS      localhost.

facebook.com            CNAME   .
*.facebook.com          CNAME   .

instagram.com           CNAME   .
*.instagram.com         CNAME   .

tiktok.com              CNAME   .
*.tiktok.com            CNAME   .

Nesse tipo de zona, o CNAME . indica que o BIND deve responder com NXDOMAIN, ou seja, informar ao cliente que aquele nome não existe. O registro sem * bloqueia o domínio principal, como facebook.com, enquanto o registro com * bloqueia também subdomínios, como www.facebook.com, m.facebook.com ou qualquer outro nome abaixo dele.


Depois de criar os arquivos, valide a configuração e recarregue o serviço:

sudo named-checkconf /etc/bind/named.conf
sudo named-checkzone bloqueios.rpz /etc/bind/db.bloqueios.rpz
sudo rndc reload

Para testar, consulte diretamente o seu servidor DNS:

dig facebook.com @127.0.0.1
dig www.facebook.com @127.0.0.1

A resposta esperada é NXDOMAIN. Isso significa que o bloqueio está sendo aplicado pelo resolvedor DNS. É importante lembrar que esse bloqueio só funciona para os clientes que realmente usam esse servidor DNS. Se o usuário configurar outro resolvedor, como um DNS público externo, ou usar DNS-over-HTTPS no navegador, ele pode contornar essa política. Portanto, em redes controladas, o ideal é combinar essa configuração com regras de rede que obriguem os clientes a usarem o DNS interno.



TSIG - Transaction Signature​

O TSIG veio para melhorar a segurança durante a transferência de zona, já que ele cria uma autenticação no nível de transação. A garantia fornecida pelo TSIG pode ser usada para consultas, transferência e atualizações.


O TSIG usa uma combinação de segredos compartilhados e hashing unidirecional para confirmar se o host que está fazendo a requisição está autorizado a acessar os dados, só estará autorizado quem tiver essa chave.


Só o fato de usar TSIG entre servidores primários e segundários cria uma boa camada de proteção, mas além disso, não podemos nos esquecer de adicionar transferências baseadas em IP, ou seja, só permitir transferência para endereços que conhecemos e usar ACL para facilitar.


Antigamente, o utilitário dnssec-keygen era usado para gerar chaves TSIG. Ele criava dois arquivos referentes à mesma chave secreta compartilhada, mas, para configurar o TSIG, utilizávamos apenas o conteúdo da chave. Depois da versão 9.15 do Bind (se não me falha a memória), foi adicionado um utilitário apenas para gerar as chaves TSIG, nesse exemplo vou usar ambos os utilitário para demontrar como se faz.


Primeiro precisamos gerar uma chave secreta, essa chave pode ser criada manualmente (ela precisa estar codificada com base 64) ou ser gerada de algumas maneiras diferentes, sendo uma delas, pelo servidor BIND.


## No Centos

# Crie o diretório abaixo:
$ sudo mkdir /var/named/tsig-keys

# Entre no diretório abaixo:
$ cd /var/named/tsig-keys

# Gere a chave no servidor Centos:
$ sudo dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST centos.te
Kcentos.te.+165+19278

# Com isso foram geradas duas chaves (uma pública e uma privada):
$ ls -l
total 8
-rw-------. 1 root root 118 Dez  2 23:47 Kcentos.te.+165+19278.key
-rw-------. 1 root root 232 Dez  2 23:47 Kcentos.te.+165+19278.private

# Não se esqueça de mudar o usuário e grupo das chaves:
$ sudo chown named. *

# Copie a chave que está no arquivo privado:
$ sudo grep -i 'key' Kcentos.te.+165+19278.private 
Private-key-format: v1.3
Key: sT8JiBiDEU1ouxMNL7Bk2FFXoxp+6Tf4oJ2FpEAsW0mdJivspYlugINouBdltRWKRNBjyMSJxlVytL2XDkndyg==

Esse comando vai gerar uma chave HOST usando o código de autenticação de mensagem chamado de HMAC-SHA512, o tamanho será de 512 bits. O centos.te é o arquivo onde tudo ficará armazenado.


Agora acesse o arquivo de configuração para adicionar a chave:

/etc/named.conf
## Add abaixo ao final do arquivo (deve ser adicionada fora da cláusula Options):
key "centos.te" {
    algorithm hmac-sha512;
    secret "sT8JiBiDEU1ouxMNL7Bk2FFXoxp+6Tf4oJ2FpEAsW0mdJivspYlugINouBdltRWKRNBjyMSJxlVytL2XDkndyg==";
};

# Agora dentro da cláusula Option (ainda no mesmo arquivo),
# Adicione a opção abaixo:
allow-transfer { key centos.te; };

Agora vamos fazer as modificações no Debian:

/etc/bind/named.conf.local
## Add abaixo ao final do arquivo:
key "centos.te" {
    algorithm hmac-sha512;
    secret "sT8JiBiDEU1ouxMNL7Bk2FFXoxp+6Tf4oJ2FpEAsW0mdJivspYlugINouBdltRWKRNBjyMSJxlVytL2XDkndyg==";
};

# Agora adicione a opção abaixo ao final do arquivo:
server 192.168.121.154 {
    keys { centos.te; };
};

Agora verifique se existem erros de configuração e caso não tenha, reinicie o Bind:

$ sudo named-checkconf

# Reinicie:
$ sudo rndc reload

# Agora force uma retransferência de zona (no Debian):
$ sudo rndc retransfer centos.te

# Veja se deu certo:
$ sudo grep 'centos' /var/log/bind/transfers
03-Dec-2022 00:58:28.187 zone centos.te/IN: Transfer started.
03-Dec-2022 00:58:28.187 transfer of 'centos.te/IN' from 192.168.121.154#53: connected using 192.168.121.135#54655 TSIG centos.te
03-Dec-2022 00:58:28.191 zone centos.te/IN: transferred serial 2: TSIG 'centos.te'
03-Dec-2022 00:58:28.191 transfer of 'centos.te/IN' from 192.168.121.154#53: Transfer status: success
03-Dec-2022 00:58:28.191 transfer of 'centos.te/IN' from 192.168.121.154#53: Transfer completed: 1 messages, 8 records, 323 bytes, 0.004 secs (80750 bytes/sec)

### Funcionou !!!

Eu coloquei sempre a chave TSIG dentro do arquivo onde ficam as configurações dos domínios, assim como a declaração de qual chave ele deve usar para determinado IP. O correto seria deixar a chave num arquivo onde somente o usuário e grupo do Bind consigam ler e escrever, ai depois é só importar essa chave no arquivo de configuração principal.


Outro detalhe é que colando o allow-transfer no arquivo de configuração principal ele será Global, no caso, todos devem ter essa mesma chave compartilhada, mas o ideal mesmo seria colocar dentro do domínio, assim cada domínio teria sua chave.

### Exemplo de como ficaria

## No CentOS:
key "centos-tsig" {
        algorithm hmac-sha512;
        secret "lOKe5bKOiz/rGOPuWj38yF1JE93d5sZyljeC11VWzORTqD2E5m4IGsjY080m8EeafpenVUrqz4Yftfr+wuYWdA==";
};

key "ubuntu-tsig" {
        algorithm hmac-sha512;
        secret "sT8JiBiDEU1ouxMNL7Bk2FFXoxp+6Tf4oJ2FpEAsW0mdJivspYlugINouBdltRWKRNBjyMSJxlVytL2XDkndyg==";
};

server 192.168.121.135 {
        keys { ubuntu-tsig; };
};

zone "centos.te" IN {
        type master;
        file "/var/named/zones/centos.te.zone";
        allow-transfer {  key centos-tsig; };
};



## No Debian:
key "ubuntu-tsig" {
        algorithm hmac-sha512;
        secret "sT8JiBiDEU1ouxMNL7Bk2FFXoxp+6Tf4oJ2FpEAsW0mdJivspYlugINouBdltRWKRNBjyMSJxlVytL2XDkndyg==";
};

key "centos-tsig" {
        algorithm hmac-sha512;
        secret "lOKe5bKOiz/rGOPuWj38yF1JE93d5sZyljeC11VWzORTqD2E5m4IGsjY080m8EeafpenVUrqz4Yftfr+wuYWdA==";
};


server 192.168.121.154 {
        keys { centos-tsig; };
};

zone "ubuntu.te" {
        type master;
        file "/etc/bind/db.ubuntu.te";
        allow-transfer {  key ubuntu-tsig; };
};

No exemplo acima estou configurando um chave para cada domínio, mas perceba que mesmo assim ainda tenho que declarar o server corretamente.



DNSSEC - Domain Name System Security Extensions​

O DNSSEC (Domain Name System Security Extensions), é um conjunto de extensões criadas para resolver uma limitação importante do DNS tradicional, que é o fato do DNS não ter um mecanismo forte para provar que uma resposta recebida é verdadeira.


Quando um resolvedor consulta, por exemplo, o endereço IP de www.exemplo.com.br, ele recebe uma resposta DNS e normalmente confia nela. O problema é que, sem DNSSEC, um atacante pode tentar falsificar essa resposta, envenenar o cache de um resolvedor ou interferir no caminho da consulta para fazer o usuário chegar a um endereço errado.


O DNSSEC existe para dar autenticidade e integridade às respostas DNS. Em outras palavras, ele permite que o resolvedor verifique se a resposta realmente veio da zona autoritativa correta e se os dados não foram alterados no caminho. Portanto, o DNSSEC ajuda quem consulta a ter certeza de que a resposta recebida é legítima, ou seja, ele protege o resolvedor e o usuário final contra respostas DNS falsas.


O funcionamento é baseado em criptografia de chave pública. A zona DNS é assinada com uma chave privada, que deve ficar protegida. A chave pública correspondente é publicada no próprio DNS por meio de registros DNSKEY. As respostas passam a vir acompanhadas de assinaturas digitais, normalmente registros RRSIG, e o resolvedor/validador usa as chaves públicas para verificar se aquelas assinaturas batem com os dados recebidos.


Para que essa validação seja confiável na Internet pública, não basta assinar apenas a zona. É necessário criar uma cadeia de confiança. Essa cadeia normalmente começa na zona raiz, passa pelo TLD (como .br, .com) e chega até o domínio final.


É aí que entra o registro DS. Em vez de simplesmente "enviar a chave pública para o gTLD", o mais correto é dizer que o operador do domínio publica ou informa ao registrar um registro DS, gerado a partir da chave da zona. Esse DS é publicado na zona pai e permite que os resolvedores validem a ligação entre a zona pai e a zona filha.


Quando um domínio está com DNSSEC corretamente configurado, um resolvedor/validador consegue seguir essa cadeia de confiança e confirmar se a resposta é válida. Se alguém tentar alterar o IP de um domínio no caminho, ou tentar inserir uma resposta falsa no cache do resolvedor, a assinatura não vai bater.


Nesse caso, o resolvedor rejeita a resposta. Em BIND, quando a validação DNSSEC está habilitada e uma resposta de uma zona assinada falha na validação, o resolvedor retorna erro, normalmente SERVFAIL, para o cliente.


O DNSSEC é usado principalmente em dois pontos da infraestrutura DNS: no servidor autoritativo, onde a zona é assinada, e no servidor recursivo, onde as respostas são validadas. O servidor autoritativo publica os registros normais da zona, como A, AAAA, MX, NS e TXT, junto com os registros adicionais do DNSSEC. Já o resolvedor recursivo valida essas informações antes de entregá-las ao cliente.


Para o usuário final, isso geralmente é transparente, ele apenas tenta acessar um domínio, e o resolvedor decide se a resposta pode ser confiável ou não.


Assim que o Bind é instalado ele já vem com as chaves públicas dos Root Server:

# No Debian:
/etc/bind/bind.keys

# No CentOS:
/var/named/dynamic/managed-keys.bind

Vamos assinar a zona DNS que está no servidor Debian.

# Crie o diretório abaixo:
$ sudo mkdir /var/cache/bind/dnssec-keys

# Entre no diretório:
$ cd /var/cache/bind/dnssec-keys

# Gere as chaves:
$ sudo dnssec-keygen -a RSASHA512 -b 1024 -n ZONE ubuntu.te

# -a RSASHA512 = Algoritmo usado para as chaves;
# -v 1024 = Tamanho da chave em bits
# -r /dev/urandom = Valores randômicos para a entropia.

# Veja as chaves:
$ sudo ls -l
total 8
total 8
-rw-r--r-- 1 root root  428 Dec  5 17:29 Kubuntu.te.+010+62301.key
-rw------- 1 root root 1013 Dec  5 17:29 Kubuntu.te.+010+62301.private


# Vou listar o conteúdo de ambos porque vamos usá-los:
$ cat Kcentos.te.+003+14111.private
Private-key-format: v1.3
Algorithm: 10 (RSASHA512)
Modulus: pHAJhLnAXxsabdiSBEgiCAK3RGc70aqSkOAgb/VIdISz1DSqd3pVF7t7hld8ui7FcUA1LT8ILMztMgJFiTtK/li51pnmMQWITY11uGeviPAet1pFIImYeg3jZbWzSnyYZkHySl5RY+kxLmwPaArCc85v0Wfd8+gmuT+/TqxaOW0=
PublicExponent: AQAB
PrivateExponent: jj6svTfCBYN4lVUm2rVbWvqednmm8XRQXSrEZJUWHFU/Cm6Ul84nFeSEsm2z44raGWGlnoJMHBUZio0UgeXctE4KqASxQTa+Cj/PRYfV65X497XWyyLSPsXEloThFNUjiN/HEgTQOdK21V3No9Mu1o5XzU3FyU2urCLoWl4tfjE=
Prime1: 0ssnPFwlNlWEnA0FxlRkqMhhTdf0btOR9rNx6WdHBsNWfFyJvDfqXscJnXEGlYRa036sywskrs5C5ftZq1+lpw==
Prime2: x7Ph2mGvlQpbRvI4PiQgO6820udzevbAf1tRssth9A0sOS9wM4v6rKPfB1uGI6RlUz0rc4AkOoUM6aGUDQbyyw==
Exponent1: SBiBt+xQMfA35eOyWO4ea3f1h9lX2dv07WrciBbxvQdseiZwWXbKa1YqHLY+qT7WjcWiteN+zWbwjJZWSf3xuw==
Exponent2: QDzLpKyRhzaan9qgXtTODYTR9MuAqQggaZcdU476hj+KfyaUR/B6BPh9cGdvYZ2q/jiJ9pA8lxpfSfOwpPQcOw==
Coefficient: sZykbUPU+SbLRJZcRKuGBHVcXZYdL7vYp6fjv6tb5K373/yz8V89HI6Hs1DGxd/8bgmHUcYz4mM1ZisvjRi5tQ==
Created: 20221205172943
Publish: 20221205172943
Activate: 20221205172943


# Chave pública:
$ cat Kubuntu.te.+010+62301.key 
; This is a zone-signing key, keyid 62301, for ubuntu.te.
; Created: 20221205172943 (Mon Dec  5 17:29:43 2022)
; Publish: 20221205172943 (Mon Dec  5 17:29:43 2022)
; Activate: 20221205172943 (Mon Dec  5 17:29:43 2022)
ubuntu.te. IN DNSKEY 256 3 10 AwEAAaRwCYS5wF8bGm3YkgRIIggCt0RnO9GqkpDgIG/1SHSEs9Q0qnd6 VRe7e4ZXfLouxXFANS0/CCzM7TICRYk7Sv5YudaZ5jEFiE2Ndbhnr4jw HrdaRSCJmHoN42W1s0p8mGZB8kpeUWPpMS5sD2gKwnPOb9Fn3fPoJrk/ v06sWjlt

Agora copie a chave pública para adicionarmos ela a nossa zona.

# Edite o arquivo abaixo:
$ sudo vim /etc/bind/db.ubuntu.te

## Cole a chave no final do arquivo ##
ubuntu.te. IN DNSKEY 256 3 10 AwEAAaRwCYS5wF8bGm3YkgRIIggCt0RnO9GqkpDgIG/1SHSEs9Q0qnd6 VRe7e4ZXfLouxXFANS0/CCzM7TICRYk7Sv5YudaZ5jEFiE2Ndbhnr4jw HrdaRSCJmHoN42W1s0p8mGZB8kpeUWPpMS5sD2gKwnPOb9Fn3fPoJrk/ v06sWjlt



### Seu arquivo deverá ser similar ao abaixo:
$TTL 1h
@       IN      SOA     dns.ubuntu.te. admin.ubuntu.te. (
        20      ; Serial
        3h      ; Refresh after 3 hours
        1h      ; Retry after 1 hour
        1w      ; Expire after 1 week
        1h )    ; Negative caching TTL of 1 hour

        IN      NS      dns.ubuntu.te.
@       IN      NS      ns2.ubuntu.te.
                MX      5       dns

dns.ubuntu.te.  A       192.168.121.135 ; glue record
ns2             A       192.168.121.154
ftp             A       192.168.121.200
135             PTR     dns.ubuntu.te.
154             PTR     ns2.ubuntu.te.
200             PTR     ftp.ubuntu.te.
ubuntu.te. IN DNSKEY 256 3 10 AwEAAaRwCYS5wF8bGm3YkgRIIggCt0RnO9GqkpDgIG/1SHSEs9Q0qnd6 VRe7e4ZXfLouxXFANS0/CCzM7TICRYk7Sv5YudaZ5jEFiE2Ndbhnr4jw HrdaRSCJmHoN42W1s0p8mGZB8kpeUWPpMS5sD2gKwnPOb9Fn3fPoJrk/ v06sWjlt

Agora vamos assinar a zona:

# Assine a zona:
$ sudo dnssec-signzone -P -o ubuntu.te /etc/bind/db.ubuntu.te /var/cache/bind/dnssec-keys/Kubuntu.te.+010+62301.private
/etc/bind/db.ubuntu.te.signed

# -P
#    Disable post sign verification tests.

#    The post sign verification test ensures that for each algorithm
#    in use there is at least one non revoked self signed KSK key,
#    that all revoked KSK keys are self signed, and that all records
#    in the zone are signed by the algorithm. This option skips
#    these tests.

# -o = Domínio;

# /etc/bind/db.ubuntu.te = Arquivo onde está o SOA;

# /var/cache/bind/dnssec-keys/Kubuntu.te.+010+62301.private = Chave privada.

Com isso a zona foi assinada:

$ sudo ls dsset-ubuntu.te. 
dsset-ubuntu.te.

# Veja:
$ sudo cat dsset-ubuntu.te.
ubuntu.te.      IN DS 62301 10 2 54070ECD801D542D250C207C26A108AF751A9EE402AE468CDC876F5C 225A455E

# Outro arquivo gerado após assinar:
$ sudo ls /etc/bind/db.ubuntu.te.signed
/etc/bind/db.ubuntu.te.signed


# Ele possuí os subdomínios:
$ sudo cat /etc/bind/db.ubuntu.te.signed 
; File written on Mon Dec  5 17:35:09 2022
; dnssec_signzone version 9.16.1-Ubuntu
ubuntu.te.      3600    IN SOA  dns.ubuntu.te. admin.ubuntu.te. (
                    20         ; serial
                    10800      ; refresh (3 hours)
                    3600       ; retry (1 hour)
                    604800     ; expire (1 week)
                    3600       ; minimum (1 hour)
                    )
            3600    RRSIG   SOA 10 2 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    I8e6jF2NUssRU5wi8tW5x2kwowsQrmSwDfnI
                    ogQkxpo2cSfYI41dTi0T6PJOKeSsj36f6urx
                    gTRsciaMeehnvtzZbNKheiEsFsY8jTzeMamT
                    751eDvV3YR0HGNMQQU8zOEpQpiif8Y9mE4+q
                    qDRzLCEXom45ZOfi7H4jGS0uNvM= )
            3600    NS  dns.ubuntu.te.
            3600    NS  ns2.ubuntu.te.
            3600    RRSIG   NS 10 2 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    PyCZG20RH7qHEOVmLo5QZg9kWfmQvfKqio87
                    +Aol1dP9qzFZ3j7omLwZ9P71aP8YqBLuKx6U
                    CEDa3JZuVDY36K71QWIoO5luVdR3ERQbBGcJ
                    RaUL9GjRozbhL4qewEzAuKHl+UWIYGOrFuU6
                    tbiJunuPbthaNMrjUtoy77Ue1+c= )
            3600    MX  5 dns.ubuntu.te.
            3600    RRSIG   MX 10 2 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    a8K/N/jzvcnym1ZuW+UliodOTsXyZwlQuDZ5
                    W1u0aj/lZDap5QqJmRnpyEuCjR/HGmgryqjt
                    ljhy1u4HHV1zJRVpr/B/p2EuRtfRT7C2jATO
                    zXbhmPSzxeqI86rQEO3BsiUaPVN0myQr52rS
                    77Pr+oZH2h1aMIXIdiUXw1iMePs= )
            3600    NSEC    135.ubuntu.te. NS SOA MX RRSIG NSEC DNSKEY
            3600    RRSIG   NSEC 10 2 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    MSPY6T9AgSTrlxG1PSmz/s4w1R/NJKuBgnvD
                    eJ5pT3hO7D0xcwhRoaP7rFj4zrPJep08Ysl2
                    LLP0NHpx9+SNzRBWIOCUzKaIitsPKD2dzAOM
                    6cqX+oRq4YU3OLVAABLV0vnC/ke4HGY8A40W
                    u9/EteX+eTBq3dn1F7JloMtva6o= )
            3600    DNSKEY  256 3 10 (
                    AwEAAaRwCYS5wF8bGm3YkgRIIggCt0RnO9Gq
                    kpDgIG/1SHSEs9Q0qnd6VRe7e4ZXfLouxXFA
                    NS0/CCzM7TICRYk7Sv5YudaZ5jEFiE2Ndbhn
                    r4jwHrdaRSCJmHoN42W1s0p8mGZB8kpeUWPp
                    MS5sD2gKwnPOb9Fn3fPoJrk/v06sWjlt
                    ) ; ZSK; alg = RSASHA512 ; key id = 62301
            3600    RRSIG   DNSKEY 10 2 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    H75U/xU+EFqmhI8RMScpWGF6M88pzipta3J/
                    Uy4KaT5nnGm4Gup3NdPze7W0pa3Hkumhp9PF
                    LFJkgpSg+TowvA5/JhDbO7Hhrbgl0Jtla/BI
                    wTrvjL2gApLXnb7kECLrhlaM6KhalSy+0EO4
                    iZPJVzg9trB62kfLaQsUCQQwXp4= )
135.ubuntu.te.      3600    IN PTR  dns.ubuntu.te.
            3600    RRSIG   PTR 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    VATjqke685X6T9YVUpJHSlPzkJwaKL2uibEU
                    oXg5PDh5pCKcG6bDJ51IsdFhfLw8M90rjKLQ
                    Ky3tBkrFCkO6k4uVDUB6x0ksLm5zB/vZR3f2
                    YVpBfSs9qn7XJRVrcVGu5/4fekfJZCKuUSiA
                    llolYC6SKtPcDFEon38ZsjfNT/o= )
            3600    NSEC    154.ubuntu.te. PTR RRSIG NSEC
            3600    RRSIG   NSEC 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    baeZnRDiUg7jQGIkyO8QJ/jbkXEj04Onp6W2
                    wry6F20Kk6ElPw4DH7bprfRtbSMrq9OFTQPa
                    BiWWCkcUWIQ3JMkQVxXiOgVCtnJl0fBL8jXl
                    skB5Xu7ltM13kXsK+8+OmyPyvr65M/unBe3t
                    nAWJ6bvvAf0Zzjfk1ihhtvmvPMw= )
200.ubuntu.te.      3600    IN PTR  ftp.ubuntu.te.
            3600    RRSIG   PTR 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    koklLK1N3TztH7LOlmftCMK9BdxRkRtmYvjI
                    qUAIx9ExpUfHuoG/+kme0DtxQ/AidcDzoH9H
                    +/qNVOoybVHK2iQY71fkjSQjJVBf5IMyYpdd
                    v0IE02EpFcxuSnkZ07TFxmPly66MUx4dRYzY
                    /cmQrSgpD3ghDU7H4xNSXDFUk/k= )
            3600    NSEC    dns.ubuntu.te. PTR RRSIG NSEC
            3600    RRSIG   NSEC 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    SGtTFWNxjqxEPAWkt/PgISIlCeXdbMqS2+ab
                    a1TjhrybhDIjZ0NrKoAeWp9wqKZvmgcx2v2s
                    S8j7AHXIH1fUTUXRv62QCZp/RjBhK6Ci4LVQ
                    LwyZGnGyvopeIqO91+4fOISun2dF4ijAcLKw
                    lqIMqmSAqEzIvNoVN4r0bKpATvo= )
dns.ubuntu.te.      3600    IN A    192.168.121.135
            3600    RRSIG   A 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    E7ptiej21F6WuoO0zxe4szkdh0Ar+NFuddN3
                    SNPmv5dPqg0kDA7EintYr+nAy6RavNp7r+3t
                    /10VaoQQxBlae5LSOngu0oHhR1x+I3JXNcvb
                    JmAwamIIxQZjr4/cbTC/E6No1IOANec+dhHW
                    8vweCEgpRIiEEaHihnoHAJlcGxY= )
            3600    NSEC    ftp.ubuntu.te. A RRSIG NSEC
            3600    RRSIG   NSEC 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    kVUeMEtvQfEzRfeIc+oskbS7g3v9uvGyo8ve
                    2ErAW8kmePp/whtdGARXsSKOwGdi8twrKAeG
                    tX7angwq5G7KoLWfeG3h7Qrwp2rrmQi6ZRvq
                    AEU0TbKiYe/nGBwQT7RHBQfpYNlX1Bej21bm
                    QhVBgQXxZtulSbN3Ls4K6wLy+Z4= )
154.ubuntu.te.      3600    IN PTR  ns2.ubuntu.te.
            3600    RRSIG   PTR 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    e9saGDlgwuUzOcfNb+yP13ewxvEJvxP3tvlT
                    F/h/CMnXAOl+NhYs9HtP39XfQStygWuLZinN
                    /wUqBXzigMTCDGQg9ExkfFDEySjKXwxFzvai
                    RUmwbhBov5TUbX6HJ8++KHuPEx31k5pURyBF
                    3hjNREnG9i9tOP8nLE/AGFJI690= )
            3600    NSEC    200.ubuntu.te. PTR RRSIG NSEC
            3600    RRSIG   NSEC 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    VxJVpVZRgaE251mlBAXdOpvkjEE1Dn1U5Fyg
                    oq6TQKEhCALo/6T0R4uC+txqKDlxgzU9KkDF
                    iMCQOONQ+KUKfKMNMFwMpj6obmpVLHV/BClL
                    eQGtK8jOAvrFebCWPhfrSq2h8h1ozr4IwtkH
                    1SKiWcOf1zs+xmdgx1uEInbwnc0= )
ns2.ubuntu.te.      3600    IN A    192.168.121.154
            3600    RRSIG   A 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    V53TmbhKimEeqPlJwtjLvM+rq6Q3SaUuar85
                    oPDjxRq939pljDIrUxtT9cDX8qtseQspZqll
                    C3tiDv1+jyo5YKicBP1Y0wkfAz4W4kr2Kpiw
                    j/DFj9TgitQRCxylarggFlPI0ogFG+fkk9yB
                    /djwHNcAN+9nO7EoJ9JCGHhYqo4= )
            3600    NSEC    ubuntu.te. A RRSIG NSEC
            3600    RRSIG   NSEC 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    d8Kqr23/ahcMY3BlWNQ5N71NE1MxHCG1LBd9
                    7ZV+CJpYlaGcXrWiuynpHFNR6osrUXv0YpiZ
                    yA8HAASoeKLm+rvuLxWoEFI1Wj9eFuQBNMfP
                    wWtW7C6njR+QV8K8mQ7Dg5tYwt6CmH15nYnI
                    E+TT7czK6vB3rxA/db4N41XlphI= )
ftp.ubuntu.te.      3600    IN A    192.168.121.200
            3600    RRSIG   A 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    AYqN5dCJ8dZ2Yyp/gRlNr/oEJPQzJI4w1d8F
                    ipofU1Hrkx0zFDAHzqLGo2q2tGvTeHaJD0PG
                    BwJIXy50sQNd9efn4Wgx3+Q8hl/eDWHfOIIl
                    R/j4ogZmpL+0J1XXiPPVRB8YVWR3mHzSf8Fr
                    bkBR7WUfP8GfZr7VQ/A7nE/PL34= )
            3600    NSEC    ns2.ubuntu.te. A RRSIG NSEC
            3600    RRSIG   NSEC 10 3 3600 (
                    20230104163509 20221205163509 62301 ubuntu.te.
                    LfAyrfbUcxMpicri1YkWIAqXK+EdcdAzpe0w
                    pO2t/ad/WzD5AlJkSQResRu+ITTvai8rTevI
                    ObfHvIL2oEHRE+AGszsp9MQW+xqziJ1qBO2k
                    RT89il+MYOIKqzPcjoZ3LN306V5FGPNVdUFT
                    Fskmcx74xPG7Kdr+89LgQJZfY9o= )

Por fim, temos que mudar o arquivo da zona, ao invés de fornecer o arquivo com o SOA atual, temos que fornecer o arquivo assinado.

# Edite o arquivo abaixo:
$ sudo vim /etc/bind/named.conf.local

## Mude o 'file' da zona assinada, veja como era ###
zone "ubuntu.te" {
        type master;
        file "/etc/bind/db.ubuntu.te";
        allow-transfer {  key ubuntu-tsig; };
};


### Veja como ficou ###
zone "ubuntu.te" {
        type master;
        file "/etc/bind/db.ubuntu.te.signed";
        allow-transfer {  key ubuntu-tsig; };
};



# Agora verifique a configuração:
$ sudo named-checkconf

# Reinicie o Bind:
$ sudo rndc reload

# Podemos ver a chave com o comando abaixo:
$ dig @127.0.0.1 DNSKEY ubuntu.te +multiline

; <<>> DiG 9.16.1-Ubuntu <<>> @127.0.0.1 DNSKEY ubuntu.te +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25853
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 64845a1dda9d307601000000638e2cf6d20dc9dc033c63be (good)
;; QUESTION SECTION:
;ubuntu.te.     IN DNSKEY

;; ANSWER SECTION:
ubuntu.te.      3600 IN DNSKEY 256 3 10 (
                AwEAAaRwCYS5wF8bGm3YkgRIIggCt0RnO9GqkpDgIG/1
                SHSEs9Q0qnd6VRe7e4ZXfLouxXFANS0/CCzM7TICRYk7
                Sv5YudaZ5jEFiE2Ndbhnr4jwHrdaRSCJmHoN42W1s0p8
                mGZB8kpeUWPpMS5sD2gKwnPOb9Fn3fPoJrk/v06sWjlt
                ) ; ZSK; alg = RSASHA512 ; key id = 62301

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 05 17:40:06 UTC 2022
;; MSG SIZE  rcvd: 214


DANE - DNS-based Authentication of Named Entities​

A Autenticação de Entidades Nomeadas baseada em DNS, conhecida como DANE, é um mecanismo que usa DNSSEC para associar certificados ou chaves públicas a nomes de domínio e serviços específicos. A ideia principal é permitir que o dono de um domínio publique, no próprio DNS, qual certificado, chave pública ou autoridade certificadora deve ser aceita para determinado serviço.


Essa informação é publicada por meio de um registro chamado TLSA, que só faz sentido do ponto de vista de segurança quando a zona está protegida por DNSSEC, porque é o DNSSEC que garante a autenticidade e a integridade desse registro. Para entender por que o DANE existe, primeiro é preciso entender o modelo tradicional de certificados TLS.


Quando acessamos um serviço protegido por TLS, como HTTPS, SMTP com STARTTLS ou DNS over TLS, o servidor apresenta um certificado X.509. Esse certificado normalmente é emitido por uma Autoridade Certificadora. Os sistemas operacionais, navegadores e aplicações mantêm listas de CAs confiáveis e aceitam certificados emitidos por elas. O problema é que esse modelo depende da confiança em várias autoridades certificadoras. Se uma CA for comprometida, enganada ou emitir um certificado indevido, um atacante pode conseguir um certificado aparentemente válido para um domínio que ele não controla.


O DANE surge justamente para reduzir essa dependência cega do conjunto global de CAs. Em vez de aceitar qualquer certificado emitido por qualquer autoridade certificadora confiável pelo sistema, o domínio pode declarar no DNS qual certificado ou qual chave pública deve ser aceito para aquele serviço.


Também pode declarar que apenas uma CA específica deve ser usada para assinar o certificado daquele serviço. Assim, o controle passa a ficar mais próximo do operador do domínio, que já controla a zona DNS e, com DNSSEC, consegue publicar essa informação de forma autenticada.


O registro usado para isso é o TLSA como dito anteriormente. Esse registro é publicado usando um nome que identifica o serviço, o protocolo e o host. Por exemplo, para um serviço HTTPS na porta 443 de www.exemplo.com.br, o nome do registro seria algo como _443._tcp.www.exemplo.com.br. Isso é importante porque um mesmo host pode usar certificados diferentes em portas diferentes. O certificado usado no HTTPS pode não ser o mesmo certificado usado no servidor de e-mail.


A partir daqui, toda explicação de DANE é conteúdo extra, não sendo obrigatório para estudo da LPIC-2, ou seja, não cai na LPIC-2. Para continua estudando, vá para o próximo tópico Enjaulamento de DNS.


Quando uma aplicação compatível com DANE se conecta a um serviço protegido por TLS, ela consulta o registro TLSA correspondente àquele host, porta e protocolo. Em seguida, valida esse registro usando DNSSEC. Se o registro TLSA for autêntico, a aplicação compara a informação publicada no DNS com o certificado apresentado pelo servidor. Se os dados combinarem, o certificado é aceito. Se não combinarem, a conexão deve ser considerada inválida, mesmo que o certificado pareça aceitável pelo modelo tradicional de CAs.


Na prática, o TLSA pode carregar a chave pública completa, o hash da chave pública ou o hash do certificado. O registro também possui campos que indicam como essa comparação deve ser feita. O campo de uso define a relação do registro com a autoridade certificadora ou com o certificado final, o seletor indica se a comparação será feita contra o certificado inteiro ou apenas contra a parte da chave pública, e o tipo de correspondência indica se o valor publicado é o dado completo, um hash SHA-256 ou um hash SHA-512.


Vamos ver como fazer usso do DANE. Primeiro acesse o site do huque.com, esse site vai nos ajudar a gerar o registro TLSA. Agora você precisa ter o certificado de um site, pode exportar de qualquer site. Vou desmontrar como fazer com o GitHub:

# Obter o certificado do github:
$ openssl s_client -servername github.com -connect github.com:443 2>/dev/null | openssl x509 -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            05:18:9a:54:eb:e8:c7:e9:03:e0:ab:0d:92:55:45:de
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
        Validity
            Not Before: Mar 15 00:00:00 2022 GMT
            Not After : Mar 15 23:59:59 2023 GMT
        Subject: C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:4a:b0:93:71:85:21:ec:62:3f:cb:74:c0:46:c8:
                    e7:00:dc:27:4a:32:4b:8a:d5:51:83:08:11:23:52:
                    65:c5:9d:64:75:94:10:9f:99:6d:3f:7b:fb:29:3b:
                    58:b8:37:54:78:4b:b7:3d:1c:77:7e:90:dd:bb:67:
                    23:32:5c:80:d1
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A

            X509v3 Subject Key Identifier: 
                78:AA:72:C6:71:69:68:14:B5:59:B1:9E:8B:6E:2B:40:87:42:3B:1E
            X509v3 Subject Alternative Name: 
                DNS:github.com, DNS:www.github.com
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl

                Full Name:
                  URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.2
                  CPS: http://www.digicert.com/CPS

            Authority Information Access: 
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt

            X509v3 Basic Constraints: 
                CA:FALSE
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : AD:F7:BE:FA:7C:FF:10:C8:8B:9D:3D:9C:1E:3E:18:6A:
                                B4:67:29:5D:CF:B1:0C:24:CA:85:86:34:EB:DC:82:8A
                    Timestamp : Mar 15 17:06:38.865 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:04:7D:70:D9:EF:62:46:5E:2A:CF:49:12:
                                5A:5E:5F:0C:ED:60:1D:B2:2E:1B:5C:F1:B0:74:AD:8D:
                                A4:7B:DF:27:02:21:00:8E:23:0B:F0:76:7B:69:E5:44:
                                3F:F0:E4:52:5B:70:21:2E:1C:EF:75:55:AC:6F:49:82:
                                EA:11:AC:82:3B:81:63
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 35:CF:19:1B:BF:B1:6C:57:BF:0F:AD:4C:6D:42:CB:BB:
                                B6:27:20:26:51:EA:3F:E1:2A:EF:A8:03:C3:3B:D6:4C
                    Timestamp : Mar 15 17:06:38.843 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:CD:72:4A:AF:06:1B:A9:EC:6A:40:34:
                                C7:F4:58:FB:9E:CA:D2:FC:BB:F3:C1:68:80:0E:6F:33:
                                59:78:D3:29:3A:02:21:00:C8:DF:12:D1:3A:00:9D:9F:
                                4E:36:02:16:1F:C1:35:52:A4:D6:69:13:C0:14:DA:BC:
                                99:46:99:6A:26:43:26:81
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : B3:73:77:07:E1:84:50:F8:63:86:D6:05:A9:DC:11:09:
                                4A:79:2D:B1:67:0C:0B:87:DC:F0:03:0E:79:36:A5:9A
                    Timestamp : Mar 15 17:06:38.892 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:F5:48:F9:11:DF:D7:8D:0A:63:FC:CC:
                                50:45:08:F3:1B:45:05:40:B9:A0:5A:57:3B:DE:79:ED:
                                DC:22:7B:BE:C9:02:20:2A:87:7C:12:A5:0F:3E:D1:10:
                                77:55:E5:59:3C:6C:B3:01:5B:54:3A:4B:B1:9A:D9:26:
                                C5:BA:85:57:B3:AC:C5
    Signature Algorithm: ecdsa-with-SHA384
         30:65:02:30:28:95:86:a7:ed:ec:bf:ec:b4:19:af:d5:7a:92:
         44:d7:c4:fe:31:bf:02:a2:88:6e:68:c6:4e:87:0d:6e:e4:3b:
         92:dd:42:b3:b9:11:83:e6:f7:6f:70:bd:22:9b:b9:15:02:31:
         00:ce:dc:b4:62:ab:60:31:ad:d2:91:fc:88:5e:ab:cd:ba:7d:
         43:81:d0:5c:c6:57:90:dc:60:f9:ba:e3:5b:19:da:39:51:93:
         0c:dc:0d:1f:bd:38:f3:eb:3f:85:3f:5b:51
-----BEGIN CERTIFICATE-----
MIIFajCCBPCgAwIBAgIQBRiaVOvox+kD4KsNklVF3jAKBggqhkjOPQQDAzBWMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTAwLgYDVQQDEydEaWdp
Q2VydCBUTFMgSHlicmlkIEVDQyBTSEEzODQgMjAyMCBDQTEwHhcNMjIwMzE1MDAw
MDAwWhcNMjMwMzE1MjM1OTU5WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2Fs
aWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEVMBMGA1UEChMMR2l0SHVi
LCBJbmMuMRMwEQYDVQQDEwpnaXRodWIuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAESrCTcYUh7GI/y3TARsjnANwnSjJLitVRgwgRI1JlxZ1kdZQQn5ltP3v7
KTtYuDdUeEu3PRx3fpDdu2cjMlyA0aOCA44wggOKMB8GA1UdIwQYMBaAFAq8CCkX
jKU5bXoOzjPHLrPt+8N6MB0GA1UdDgQWBBR4qnLGcWloFLVZsZ6LbitAh0I7HjAl
BgNVHREEHjAcggpnaXRodWIuY29tgg53d3cuZ2l0aHViLmNvbTAOBgNVHQ8BAf8E
BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMIGbBgNVHR8EgZMw
gZAwRqBEoEKGQGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFRMU0h5
YnJpZEVDQ1NIQTM4NDIwMjBDQTEtMS5jcmwwRqBEoEKGQGh0dHA6Ly9jcmw0LmRp
Z2ljZXJ0LmNvbS9EaWdpQ2VydFRMU0h5YnJpZEVDQ1NIQTM4NDIwMjBDQTEtMS5j
cmwwPgYDVR0gBDcwNTAzBgZngQwBAgIwKTAnBggrBgEFBQcCARYbaHR0cDovL3d3
dy5kaWdpY2VydC5jb20vQ1BTMIGFBggrBgEFBQcBAQR5MHcwJAYIKwYBBQUHMAGG
GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBPBggrBgEFBQcwAoZDaHR0cDovL2Nh
Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0VExTSHlicmlkRUNDU0hBMzg0MjAy
MENBMS0xLmNydDAJBgNVHRMEAjAAMIIBfwYKKwYBBAHWeQIEAgSCAW8EggFrAWkA
dgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yCigAAAX+Oi8SRAAAEAwBH
MEUCIAR9cNnvYkZeKs9JElpeXwztYB2yLhtc8bB0rY2ke98nAiEAjiML8HZ7aeVE
P/DkUltwIS4c73VVrG9JguoRrII7gWMAdwA1zxkbv7FsV78PrUxtQsu7ticgJlHq
P+Eq76gDwzvWTAAAAX+Oi8R7AAAEAwBIMEYCIQDNckqvBhup7GpANMf0WPueytL8
u/PBaIAObzNZeNMpOgIhAMjfEtE6AJ2fTjYCFh/BNVKk1mkTwBTavJlGmWomQyaB
AHYAs3N3B+GEUPhjhtYFqdwRCUp5LbFnDAuH3PADDnk2pZoAAAF/jovErAAABAMA
RzBFAiEA9Uj5Ed/XjQpj/MxQRQjzG0UFQLmgWlc73nnt3CJ7vskCICqHfBKlDz7R
EHdV5Vk8bLMBW1Q6S7Ga2SbFuoVXs6zFMAoGCCqGSM49BAMDA2gAMGUCMCiVhqft
7L/stBmv1XqSRNfE/jG/AqKIbmjGTocNbuQ7kt1Cs7kRg+b3b3C9Ipu5FQIxAM7c
tGKrYDGt0pH8iF6rzbp9Q4HQXMZXkNxg+brjWxnaOVGTDNwNH7048+s/hT9bUQ==
-----END CERTIFICATE-----

Depois de copiar o certificado (de BEGIN CERTIFICATE até END CERTIFICATE) vá para o site, cole o certificado no campo Enter/paste PEM format X.509 certificate here:, em Port Number coloque 443, em Transport Protocol coloque TCP e no campo Domain Name: coloque o domínio, no meu caso é github.com.


Agora clique em Generate e veja o registro DANE que é gerado:

_443._tcp.github.com. IN TLSA 3 1 1 (
                  ff77ed75e5aa20038dc9efc278442e2c6bed970e0c3e74262a0c8f2ee805
                  6caf
)

Agora é só adicionar esse registro na zona DNS, a aplicação que vai validar o certificado tem que suportar a validação do DANE também, caso contrário, não vai funcionar.


Além do site do Huque, também é possível gerar o hash e os registros TLSA localmente, usando um script. Isso é útil principalmente em ambientes de produção, onde depender de uma ferramenta web para colar certificados pode não ser o ideal.


Para esse caso, uma alternativa bastante conhecida é o chaingen, um script publicado por Viktor Dukhovni na lista dane-users. Na própria mensagem da lista, Viktor anexou os scripts tlsagen e chaingen, observando também que o chaingen não valida a integridade da cadeia de certificados.


A escolha do chaingen tem bastante peso técnico porque Viktor Dukhovni não é apenas alguém que publicou um script isolado na internet. Ele é uma das principais referências práticas em DANE para SMTP e aparece como coautor da RFC 7672, que define o uso de DANE TLS em SMTP oportunista.


Na prática, o site é uma boa forma de entender o processo e visualizar rapidamente como o registro TLSA é montado. Já o chaingen é mais interessante quando queremos automatizar ou padronizar a geração dos registros, principalmente em servidores que renovam certificados periodicamente, como acontece com certificados Let’s Encrypt.


Um exemplo de uso seria gerar os registros TLSA a partir de um arquivo contendo o certificado ou a cadeia de certificados do serviço:

$ ./chaingen github_fullchain.pem github.com:443 | grep '3 1 1 '
_443._tcp.github.com. IN TLSA 3 1 1 472d2f2d0700334669c237c221d6b2dcfe1bb9dcf47cbc1edf81165cdd5959d9

Para gerar um TLSA no formato mais comum (3 1 1), também podemos usar via CLI no Linux:

# Obtendo o certificado do site:
$ openssl s_client -connect github.com:443 -servername github.com </dev/null 2>/dev/null \
| openssl x509 -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 -binary \
| xxd -p -c 256
472d2f2d0700334669c237c221d6b2dcfe1bb9dcf47cbc1edf81165cdd5959d9


# Se você já possui o certificado, pode fazer assim:
$ openssl x509 -in github_fullchain.pem -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 -binary \
| xxd -p -c 256
472d2f2d0700334669c237c221d6b2dcfe1bb9dcf47cbc1edf81165cdd5959d9


Enjaulamento de DNS (chroot jail)​

O chroot jail é uma técnica usada para limitar a visão que um processo tem do sistema de arquivos. No caso do BIND, a ideia é fazer com que o processo named enxergue um diretório específico como se fosse a raiz do sistema, ou seja, como se aquele diretório fosse o /.


A partir desse momento, tudo que o BIND tentar acessar será resolvido dentro desse ambiente limitado. Por exemplo, se o chroot estiver em /var/named/chroot e o BIND tentar ler /etc/named.conf, na prática ele estará acessando /var/named/chroot/etc/named.conf.


É importante não confundir chroot com uma máquina virtual. O BIND não passa a rodar independente do sistema operacional, nem ganha um kernel próprio, memória isolada ou uma pilha de rede separada. Ele continua sendo um processo do mesmo sistema operacional. O chroot lembra mais um container porque limita a visão do processo sobre o sistema de arquivos.


O objetivo principal dessa configuração é reduzir o impacto caso o serviço DNS seja comprometido. Se um atacante explorar uma falha no BIND, ele não terá acesso direto ao sistema de arquivos inteiro do servidor, mas apenas ao ambiente preparado dentro do chroot.


Para que isso funcione corretamente, o ambiente chroot precisa conter tudo que o BIND precisa para executar. Isso inclui arquivos de configuração, arquivos de zona, diretórios de log, arquivos de PID, chaves usadas pelo rndc, dispositivos necessários como /dev/null e /dev/random, além de permissões corretas para leitura e escrita.


Do ponto de vista do BIND, o diretório definido como chroot passa a ser a raiz do sistema, então opções como directory, pid-file e caminhos de logs precisam ser ajustadas pensando nessa nova raiz.


No BIND, esse modo normalmente é ativado com a opção -t, que informa o diretório base do chroot. Também é recomendado executar o named com um usuário sem privilégios, usando a opção -u, porque isso combina duas camadas de proteção, o processo fica preso dentro do chroot e, ao mesmo tempo, não roda como root. Um exemplo simples seria:

named -u named -t /var/named/chroot

Essa configuração é mais avançada porque exige cuidado com caminhos, permissões e arquivos auxiliares. Um erro comum é mover o BIND para dentro do chroot, mas esquecer algum arquivo necessário para o funcionamento do serviço. Por isso, em ambientes de produção, o ideal é usar o pacote da própria distribuição quando ele já fornece suporte a bind-chroot, ou seguir um procedimento bem testado para criar manualmente o ambiente.


Veja a imagem abaixo para entender melhor a ideia do isolamento:

chroot-jail


Para usar em produção eu recomendo que leia esse tutorial para uma configuração completa. Aqui, vou demonstrar de uma forma bem simplificada.


Fazer essa tarefa é mais simples no CentOS, já que ele possui o pacote bind-chroot, que faz todo o trabalho pesado.

$ sudo yum install bind-chroot

# Pare o serviço do atual named que temos instalado:
$ sudo systemctl stop named

# Remova do Boot:
$ sudo systemctl disable named

# Agora rode o script que vai configurar e habilitar o chroot jail:
$ sudo /usr/libexec/setup-named-chroot.sh /var/named/chroot/ on

# on = habilita o bind chroot no diretório informado.


# Copie alguns arquivos para o novo local, dentro do chroot:
$ sudo cp /etc/{named.zones,rndc.key} /var/named/chroot/etc/

# Acerte a permissão:
$ sudo chown root.named /var/named/chroot/etc/{named.zones,rndc.key}

# Crie o diretório abaixo:
$ sudo mkdir /var/named/chroot/var/log/bind

# Acerte a permissão:
$ sudo chown named.root /var/named/chroot/var/log/bind

# Inicie o novo serviço:
$ sudo systemctl start named-chroot

# Habilite no Boot:
 $ sudo systemctl enable named-chroot
 
# Agora veja que o processo do named é um processo novo:
$ ps aux | grep -i named
named     2850  0.0  5.6 238800 104792 ?       Ssl  Dez05   0:00 /usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot

# -t = Define onde ficará o Root Jail do Named.

Se verificarmos a chroot jail do Bind, vamos ver que ele segue a mesma estruture de um sistema possuindo todas as libs e arquivos de configuração necessários para fazer funcionar o Chroot:

$ sudo ls -l /var/named/chroot/
total 0
drwxr-x---. 2 root named  44 Dez  5 23:04 dev
drwxr-x---. 4 root named 206 Dez  5 23:12 etc
drwxr-x---. 3 root named  19 Dez  5 23:02 run
drwxr-xr-x. 3 root root   19 Dez  5 23:02 usr
drwxr-x---. 5 root named  52 Dez  5 23:02 var

O chroot jail ajuda a limitar os danos caso alguém explore uma vulnerabilidade no BIND. Nesse cenário, o processo comprometido tende a ficar restrito ao ambiente preparado para o chroot, enxergando apenas os arquivos e diretórios disponíveis ali. Isso não impede todos os ataques, mas reduz bastante o acesso direto ao restante do sistema operacional.



Fontes importantes​

https://www.youtube.com/watch?v=_8M_vuFcdZU

https://www.huque.com/bin/gen_tlsa

https://tldp.org/HOWTO/pdf/Chroot-BIND-HOWTO.pdf