VISÃO GERAL SOBRE DNSSEC

DNS - DOMAIN NAME SYSTEM

 DNS é a abreviação de “Domain Name System”
(ou Sistema de Nome de Domínio) e serve
basicamente para fazer com que você consiga
acessar o host que esta querendo ver, usando
nomes, ao invés de números.

exemplo.foo.eng.br → 200.160.10.251
www.cgi.br → 200.160.4.2
www.registro.br → 2001:12ff:0:2::3
TIPOS DE SERVIDORES
Servidor Autoritativo:
Ao receber requisições de resolução de nome, responde um endereço caso
possua, uma referência caso conheça o caminho da resolução ou uma
negação caso não conheça

Servidor Recursivo:
Ao receber requisições de resolução de nomes, faz requisições para os
servidores autoritativos e conforme a resposta recebida dos mesmos
continua a realizar requisições para outros servidores autoritativos até
obter a resposta satisfatória
TIPOS DE DADOS QUE PODEM SER
ARMAZENADOS
Os dados associados com os nomes de domínio estão
contidos em Resource Records ou RRs (Registro de
Recursos)

Alguns Tipos Comuns de Records

SOA Indica onde começa a autoridade a zona

NS Indica um servidor de nomes para a zona
A Mapeamento de nome a endereço (IPv4)
AAAA Mapeamento de nome a endereço (IPv6)
MX Indica um mail exchanger para um nome
CNAME Mapeia um nome alternativo
TXT Campo de texto livre
COMO FUNCIONA O DNS
VULNERABILIDADES
DNS CACHE POISONING
DNS CACHE POISONING
DNS CACHE POISONING
MAN-IN-THE-MIDDLE
 Objetivo
– Conseguir interceptar o trafego da rede sem ser
identificado
– Se fazer passar por um servidor para o usuário e por um
usuário para o servidor
– Obter acesso a conteúdos protegidos, mas aprendendo
como desproteger
MAN-IN-THE-MIDDLE
MAN-IN-THE-MIDDLE
DNSSEC
 DNSSEC é uma extensão do protocolo DNS para implementar
mecanismos de segurança ao protocolo DNS.
 Permite que se possa verificar as informações recebidas, invés
de “confiar” em sua validade
 Para implementar essas funcionalidades, o DNSSEC faz uso da
criptografia de chave pública (ou criptografia assimétrica) e
introduz um novo conjunto de Resource Records (RRs) com
funções específicas: assinar outros RRs (RRSIG), divulgar a chave
pública que valida as assinaturas digitais de um determinado
domínio (DNSKEY), garantir a não existência de outros registros
(NSEC) e garantir a continuidade do "canal de segurança" na
delegação de zonas (DS).
DNSSEC
O que garante?
 Origem (Autenticidade)
 Integridade
 A não existência de um nome ou tipo

O que não garante?

 Confidencialidade
 Proteção contra ataques de negação de serviço (DoS)
CHAVES ASSIMÉTRICAS
DNSKEY
É um resource record que armazena a chave
pública da zona, que valida as assinaturas
digitais de um determinado domínio.

EXEMPLO:

foo.eng.br. 900 IN DNSKEY 256 3 5 (

AwEAAeZPN2yMs9q6kgYjFUblEwjCn
WWcPq+TGcJrD5gaXXAbP5MAqIkgZ
5J4TU1mmpL1A8gMfd/wUmBkVipXR
8FKHRajBZSRfgeKnKaQtrxNZ32Ccts
2F6Ylv9WaLXtiqebgOZtuJFpQr6pnIt/
FoOI+I7BUSNrX28VTq4jXu/qTrmM/
) ; key id = 62745
KSK E ZSK
 KSK (Key Signing Key ): Sua chave privada é
utilizada apenas para assinar o conjunto de chaves
públicas da zona.

 ZSK (Zone Signing Key): Sua chave privada é

utilizada para assinar registros autoritativos da zona:
conjunto de registros (A, AAAA, DS, CNAME, etc.),
com exceção do registro DNSKEY (assinado pela
KSK)
RRSIG
 É a assinatura de um RRset. RRset é um conjunto de records na
base de dados DNS com mesmo nome, classe e tipo. Esta
assinatura é a garantia de que as informações enviadas sobre um
domínio são verdadeiras. Isso é possível em função da utilização
de criptografia assimétrica.
 O processo de assinatura dos registros é feita off-line, ou seja, o
administrador da zona deve fazê-lo antes de publicar a zona.
 No processo de checagem o cliente calculará o hash do RRSet
recebido, usará a chave pública da zona para decifrar o RRSIG e
fará uma comparação entre o hash gerado por ele e o hash
enviado pelo servidor (RRSIG decifrado). Caso sejam iguais, então
a resposta é valida; caso contrário os dados foram alterados e
teremos uma resposta do tipo SERVFAIL.
NSEC
 NSEC (Next SECure). Esse registro armazena informações
sobre o próximo nome na zona, que agora passa a ser
ordenada. A grosso modo, cada registro mantem um
apontador, através de seu NSEC, para o próximo registro; o
último "aponta" para o primeiro. Vamos a um exemplo
(serão omitidos uma série de detalhes da definição da zona.
O objetivo é somente demonstrar o funcionamento do
NSEC):
DELEGATION SIGNER (DS)
 A ideia é armazenar um hash da KSK de uma zona em sua zona
pai e deixar a tarefa de ancorar a chave diretamente no cliente
(servidor recursivo) somente quando não tivermos como fazer isso
com a zona pai. Ou seja, se todos os domínios aplicarem esse
processo, apenas precisaremos ancorar as chaves da zona raiz no
cliente.
IMPLANTAÇÃO DE DNSSEC EM SUA ZONA

 Servidor de Nomes utilizado: bind9

 Zona em que se está implantando DNSSEC:
exemplo-dnssec.br.
 Localização dos arquivos de configuração:
 named.conf -> /etc/bind/named.conf
 Arquivo de zona de exemplo-dnssec.br. ->
/etc/bind/var/exemplo-dnssec.zone
 Diretório para chaves DNSSEC -> /etc/bind/keys
IMPLANTAÇÃO DE DNSSEC EM SUA
ZONA
O arquivo de zona para exemplo-dnssec.br. (/etc/bind/var/exemplo-
dnssec.zone) inicialmente contém o seguinte:

$TTL 86400 ; 1 day

$ORIGIN exemplo-dnssec.br.
@ IN SOA ns1.exemplo-dnssec.br. hostmaster.exemplodnssec.br.(
2005032902 ; serial
10800 ; refresh (3 hours)
15 ; retry (15 seconds)
604800 ; expire (1 week)
10800 ; minimum (3 hours)
)
IN NS ns1.exemplo-dnssec.br.
IN MX 10 mail.exemplo-dnssec.br.
ns1 IN A 192.168.2.6
www IN A 10.1.2.1
IN A 172.16.2.1
mail IN A 192.168.2.3
IMPLANTAÇÃO DE DNSSEC EM SUA
ZONA
 A configuração inicial do /etc/bind/named.conf é a seguinte
(somente a parte importante):

...

zone "exemplo-dnssec.br" {
type master;
file "/etc/bind/var/exemplo-dnssec.zone";
};

...
CONFIGURAÇÃO DO BIND
 Primeiro geramos a chave KSK, que será usada somente para
assinatura dos registros DNSKEY.
# mkdir -p /etc/bind/keys
# cd /etc/bind/keys
# dnssec-keygen -a rsasha1 -b 1280 -fKSK -r/dev/urandom
exemplo-dnssec.br
Kexemplo-dnssec.br.+005+50148

A chave gerada está em dois arquivos: Kexemplo-

dnssec.br.+005+50148.key e Kexemplo-dnssec.br.+005+50148.private.
O primeiro é a chave pública, que deverá ser incluído na zona logo
abaixo, o segundo é a chave privada que deve ser mantida de forma
segura no servidor
IMPLANTAÇÃO DE DNSSEC EM SUA
ZONA
 Em seguida, geramos a chave ZSK, que será usada somente para
assinatura dos demais registros da zona (com exceção da
DNSKEY, assinada pela KSK).

# cd /etc/bind/keys
# dnssec-keygen -a rsasha1 -b 1152 -r /dev/urandom exemplo-
dnssec.br
Kexemplo-dnssec.br.+005+39539

A chave gerada está em dois arquivos: Kexemplo-dnssec.br.+005

+39539.key e Kexemplodnssec.br.+005+39539.private.
O primeiro é a chave pública, que deverá ser incluído na zona logo
abaixo, o segundo é a chave privada que deve ser mantida de
forma segura no servidor.
IMPLANTAÇÃO DE DNSSEC EM SUA
ZONA
 Uma vez que as chaves já foram geradas, é momento de incluí-las
no arquivo da zona. A chave que será inclusa é a chave pública,
tanto da KSK quanto da ZSK.
IMPLANTAÇÃO DE DNSSEC EM SUA
ZONA
 Agora precisamos assinar o arquivo de zona. O procedimento de
assinatura consistem em ordenar o arquivo da zona, gerar os
registros NSEC, e assinar os RRsets da zona. O comando abaixo
realiza essas atividades
dnssec-signzone -K /etc/bind/keys -o exemplo-dnssec.br -g -t -k KSK_KEY
/etc/bind/var/exemplo-dnssec.zone ZSK_KEY
IMPLANTAÇÃO DE DNSSEC EM SUA ZONA
-K /etc/bind/keys informa qual o diretório que contém os
arquivos das chaves (públicas e privadas) KSK e ZSK, nesse caso
/etc/bind/keys.
-o exemplo-dnssec.br é o nome da zona, nesse caso exemplo-
dnssec.br
-g é um parâmetro usado para gerar o arquivo dsset que contém o
registro DS para possivelmente ser adicionado à zona parent.
Após a execução do comando acima com esse parâmetro, será
gerado um arquivo dsset-exemplo-dnssec.br. no diretório corrente;
-t é um parâmetro para gerar estatísticas sobre a assinatura da
zona;
-k KSK_KEY informa qual a chave KSK para assinatura do
DNSKEY;
/etc/bind/var/exemplo-dnssec.zone é o arquivo de zona
(parâmetro obrigatório);
ZSK_KEY é a chave ZSK usada na assinatura dos outros
registros da zona (parâmetro obrigatório).
IMPLANTAÇÃO DE DNSSEC EM SUA
ZONA
 Agora precisaremos alterar a configuração do bind para utilizar a
versão assinada do arquivo de zona. Para isso, edite o arquivo
named.conf e deixe-o como a seguir
IMPLANTAÇÃO DE DNSSEC EM SUA
ZONA
 Precisamos recarregar o daemon do bind para que ele
reconheça essa nova configuração. Para tal:
/etc/init.d/bind9 restart
 Isso finaliza a configuração do servidor. Agora
precisaremos divulgar de alguma forma a chave pública de
nossa KSK.
DIVULGANDO A CHAVE PÚBLICA DA
KSK
 Caso a zona parent possua DNSSEC implantado,
vamos simplesmente solicitar a inclusão do
registro DS. Esse é o método mais recomendado
para garantia da cadeia de confiança, logo
sempre que possível utilize esse método
 OBS: Caso a zona parent de seu domínio não
tenha suporte à DNSSEC, você terá que usar
outro método de divulgação da chave pública, por
exemplo, divulgando sua chave em um servidor
DLV. Caso isso seja realmente necessário,
recomendamos usar o DLV da ISC:
MÉTODOS DE TROCA DE CHAVES NO
DNSSEC
 A troca de chaves planejada vai depender da
política de chaves DNSSEC da instituição. No
caso do POP-BA, a ZSK é trocada a cada três
meses e a KSK tem validade de 2 anos.
 Existem dois métodos utilizados na troca de
chaves: pre-publish e double-signing.
MÉTODO PRE-PUBLISH
 No método pre-publish a ideia é adicionar uma ou
mais novas chaves na zona antes mesmo delas
serem de fato utilizadas para assinar registros.
 Dessa forma garante-se a disponibilidade de
ambas as chaves no cache do servidores
recursivos, que devem utilizar todas as chaves
disponíveis na validação de um registro, e evita-
se falhas pela utilização incorreta da chave na
validação.
MÉTODO PRE-PUBLISH
 Para ilustrar o funcionamento desse método,
vamos acompanhar os passos de substituição de
uma chave em uma zona fictícia. Para tal,
assumimos que o TTL de qualquer registro na
zona assinada é 24h (86400 segundos).
MÉTODO PRE-PUBLISH
1. No mínimo dois dias antes da expiração das assinaturas
da zona (poderia ser qualquer momento antes), a nova
chave (seja KSK ou ZSK) deve ser adicionada ao registro
DNSKEY da zona. A zona é então re-assinada usando a
chave atual, não a nova. A nova chave apenas estará
presente à zona, porém ainda não será usada em
nenhuma assinatura.
2. Passado-se as 24h (tempo definido do TTL ou TTL
máximo da zona), garantimos que o cache dos servidores
recursivos contém o registro DNSKEY contendo ambas as
chaves, a atual e a nova. Nesse caso, qualquer RR estará
assinado com a chave atual e ainda não temos uso claro
da nova chave.
MÉTODO PRE-PUBLISH
3. Nesse momento, a zona é re-assinada utilizando
a nova chave. A chave antiga permanece
disponível na zona.
4. A partir desse ponto e nas próximas 24h (tempo
definido do TTL ou TTL máximo da zona), a
assinatura de qualquer RR requisitado à um
servidor recursivo, por exemplo o RR A para
www.exemplo.com, pode ter sido feita com a
chave antiga (caso o RR já estava no cache) ou
com a chave nova (caso o cache tenha expirado e
o servidor recursivo obteve o registro novamente
em um servidor autoritativo
MÉTODO PRE-PUBLISH
5. Depois de 24h da assinatura da zona com a nova
chave, podemos garantir que todos os caches
contém apenas registros assinados com a nova
chave. A chave antiga pode então ser removida
do RR DNSKEY e a zona re-assinada com a
nova chave.
MÉTODO DOUBLE-SIGNING
Diferente do método de pre-publish, onde a nova
chave era adicionada à zona porém ser ter uma
utilidade clara no início, no método de double-
signing utilizamos tanto a chave atual quanto a
nova para assinar os registros da zona. Ou seja,
usando double-signing teremos duas assinaturas
para cada conjunto de RRs. Se a chave que
estiver sendo substituída for a ZSK, toda a zona
será assinada duas vezes. Já se for a KSK
somente os registros DNSKEY serão assinados
duas vezes.
MÉTODO DOUBLE-SIGNING
Uma vez que os registros de recurso são
assinados com todas as chaves, não corremos o
risco de um servidor recursivo, que armazena
uma das chaves em cache, falhe ao autenticar os
dados de uma consulta (o mesmo vale para
configuração de âncoras ou do registro DS na
zona parent). Quando todos os usuários da chave
tiverem atualizado suas configurações (o registro
DS foi atualizado na zona parent ou as âncoras de
segurança foram atualizadas), a chave antiga
pode ser removida e a zona re-assinada somente
com a nova chave.
GERÊNCIA DAS CHAVES DNSSEC

 As chaves devem ser trocadas com alguma frequência. Essa

frequência depende da política de cada domínio. De
qualquer forma, é interessante manter em local seguro (por
exemplo na Intranet de sua instituição) uma planilha que
liste as chaves que estão sendo usadas, além de
informações sobre a data de utilização (criação e troca).
 Ainda, configure duas rotinas em seu servidor de gerência
para enviar e-mails quando tiver próximo ao período de
troca das chaves:
 Um e-mail para a troca da chave KSK
 Um e-mail para a troca da chave ZSK
PROCEDIMENTO PARA SUBSTITUIÇÃO
MANUAL DE CHAVES DNSSEC

Para manter um controle sobre a utilização das chaves,

recomenda-se a utilização de uma tabela, como a seguinte,
que liste quais chaves estão sendo utilizadas e quando as
mesmas devem ser removidas.

OBS1: O campo Chave refere-se ao basename do arquivo que

contém a chave.
OBS2: Os valores dos campos Data Início e Data Fim são
determinados a partir da política de chaves da instituição
SUBSTITUIÇÃO DA KSK
 Condição Necessária: Receber e-mail de alerta
sobre a proximidade de substituição da KSK. Esse é o
primeiro passo a ser seguido no procedimento de
substituição da KSK.
 Descrição das etapas:
 Primeiro devemos gerar a nova chave. No comando abaixo,
alguns parâmetros que podem variar com sua política de
chaves, tais como algoritmo (-a rsasha1) e tamanho da
chave (-b 1280), ou com a zona em questão (nome da zona
nesse caso é exemplo-dnssec.br).
# dnssec-keygen -a rsasha1 -b 1280 -f KSK -r
/dev/urandom exemplo-dnssec.br
Kexemplo-dnssec.br.+005+50148
 Em seguida, adiciona-se essa nova chave ao arquivo de
zona.
EXEMPLO DA INCLUSÃO DA CHAVE GERADA
SUBSTITUIÇÃO DA KSK
 Então, deve-se re-assinar a zona, utilizando as
duas chaves, a nova e a atual (o comando abaixo
possui uma única linha):
dnssec-signzone -o exemplo-dnssec.br -g -t -k Kexemplo-
dnssec.br.+005+12513 -k Kexemplo-dnssec.br.+005+50148
pop-ba.zone Kexemplo-dnssec.br.+005+03977
 O comando acima irá gerar um arquivo,
provavelmente dsset-exemplo-dnssec.br.. Esse
arquivo deve ser enviado ao administrador da
zona parent
SUBSTITUIÇÃO DA KSK
Passaremos a considerar que a chave atual
agora é chave antiga (no exemplo, key-tag é
12513) e a chave nova agora é chave atual
(no exemplo, key-tag é 50148). A partir desse
momento até a remoção da chave antiga,
assinaremos a zona sempre com o comando
acima.
CONTAGEM PARA REMOÇÃO DA KSK
ANTIGA

 Condição Necessária: Receber e-mail do

administrador da zona parent notificando sobre a
alteração do registro DS. Esse é o segundo passo
a ser seguido no procedimento de substituição da
KSK.
 Descrição das etapas:
 Uma vez que a zona parent já atualizou o registro DS para a
nova chave pública KSK, basta aguardar que os servidores de
cache expirem os dados que contém a chave antiga para que
possamos removê-la da zona. Ao final desse prazo deve ser
aplicado a seguinte etapa: Remover chave KSK antiga da
zona.
REMOVER A CHAVE KSK ANTIGA DA
ZONA

 Condição Necessária: Receber e-mail de alerta

sobre a proximidade de remover a chave KSK
antiga da zona. Esse é o terceiro e último passo a
ser seguido no procedimento de substituição da
KSK.
 Passados 30 dias desde a atualização do registro
DS na zona parent com sua nova KSK, é
momento de remover a chave antiga (no exemplo,
key-tag é 12513). Para isso, edite o arquivo de
definição da zona e remova a linha que contém a
KSK antiga ($INCLUDE Kexemplo-
dnssec.br.+005+12513.key ...)
REMOVER A CHAVE KSK ANTIGA DA
ZONA
REMOVER A CHAVE KSK ANTIGA DA
ZONA

 Então, deve-se re-assinar a zona, utilizando a

chave nova/atual (key-tag = 50148):
dnssec-signzone -o exemplo-dnssec.br -t -k
Kexemplo-dnssec.br.+005+50148 pop-ba.zone
Kexemplo-dnssec.br.+005+03977
 Finalmente, recarregue a configuração no
daemon do bind:
/etc/init.d/bind9 restart
SUBSTITUIÇÃO DA ZSK
Adicionando a nova chave
 Condição Necessária: Receber e-mail de alerta sobre a
proximidade de substituição da ZSK. Esse é o primeiro
passo a ser seguido no procedimento de substituição da
ZSK.
 Primeiro devemos gerar a nova chave. No comando abaixo,
alguns parâmetros que podem variar com sua política de
chaves, tais como algoritmo (-a rsasha1) e tamanho da
chave (-b 1152), com a zona em questão (nome da zona
nesse caso é exemplo-dnssec.br).
# dnssec-keygen -a rsasha1 -b 1152 -r /dev/urandom
exemplo-dnssec.br
Kexemplo-dnssec.br.+005+39539
SUBSTITUIÇÃO DA ZSK
 Em seguida, adiciona-se esse nova chave ao arquivo de
zona e assina-se o arquivo de zona com a chave atual (não a
nova).
SUBSTITUIÇÃO DA ZSK
Então, deve-se re-assinar a zona, utilizando a chave atual:
dnssec-signzone -o exemplo-dnssec.br -t -k Kexemplo-
dnssec.br.+005+12513 pop-ba.zone Kexemplo-
dnssec.br.+005+03977
Finalmente, recarregue a configuração no daemon do bind:
/etc/init.d/bind9 restart
 Agora, configure uma rotina no seu servidor de gerência
para enviar um e-mail aos administradores da zona em 10
dias desde a configuração acima. Ao final desse prazo deve
ser aplicado a seguinte etapa: Re-assinar a zona com a
nova chave
RE-ASSINAR A ZONA COM A NOVA CHAVE
 Condição Necessária: Receber e-mail de alerta
sobre a proximidade da assinatura da zona com a
nova chave. Esse é o segundo passo a ser seguido
no procedimento de substituição da ZSK.
RE-ASSINAR A ZONA COM A NOVA CHAVE
 Passados os 10 dias desde a introdução da nova
chave na zona, é hora de usá-la na assinatura da
zona. Para isso executamos o comando de
assinatura da zona, como anteriormente, porém
agora usando a nova chave (cujo key-tag é 39539):

dnssec-signzone -o exemplo-dnssec.br -t -k
Kexemplo-dnssec.br.+005+12513 pop-ba.zone
Kexemplo-dnssec.br.+005+39539

 Recarregue a configuração no daemon do bind:

RE-ASSINAR A ZONA COM A NOVA CHAVE
 A partir desse momento consideramos que a
chave atual agora é chave antiga (no
exemplo, key-tag é 03977) e a chave nova agora
é chave atual (no exemplo, key-tag é 39539).
 Agora devemos aguardar mais 10 dias para
finalmente remover a chave antiga. Para isso
configure uma rotina no seu servidor de gerência
para enviar um e-mail aos administradores da
zona em 10 dias desde a configuração acima. Ao
final desse prazo deve ser aplicado a seguinte
etapa: Remover a chave antiga da zona
RE-ASSINAR A ZONA COM A NOVA CHAVE
 Condição Necessária: Receber e-mail de alerta
sobre a proximidade da remoção da chave antiga.
Esse é o terceiro e último passo a ser seguido no
procedimento de substituição da ZSK.
 Passados 10 dias desde a assinatura da zona, é
momento de remover a chave antiga (no exemplo,
key-tag é 03977). Para isso, edite o arquivo de
definição da zona e remova a linha que contém a ZSK
antiga ($INCLUDE Kexemplo-
dnssec.br.+005+03977.key ...).
RE-ASSINAR A ZONA COM A NOVA CHAVE
RE-ASSINAR A ZONA COM A NOVA CHAVE
 Então, deve-se re-assinar a zona, utilizando a
chave nova/atual (key-tag = 39539):
dnssec-signzone -o exemplo-dnssec.br -t -k
Kexemplo-dnssec.br.+005+12513 pop-ba.zone
Kexemplo-dnssec.br.+005+39539
 Finalmente, recarregue a configuração no
daemon do bind:
/etc/init.d/bind9 restart
IMPLANTANDO DNSSEC NO SERVIDOR
RECURSIVO
 Para que as checagens DNSSEC possam ocorrer no
servidor recursivo, precisaremos obter as chaves públicas
das zonas DNSSEC-habilitadas. Agora que a zona raiz foi
assinada, precisamos apenas ancorar sua chave pública
como Trust Anchor na configuração de servidores DNS
recursivos.
 Entretanto, manteremos também a chave de um servidor
DNSSEC Lookaside Validation (DLV), que será usada em
casos de ilhas de segurança DNSSEC
IMPLANTANDO DNSSEC NO SERVIDOR
RECURSIVO

 No bind, a partir da versão 9.7.0, a chave do

servidor DLV do ISC já está disponível na
instalação padrão. Ainda, a partir dessa versão já
temos a implementação da RFC 5011, que fala
sobre a atualização automática de âncoras de
segurança DNSSEC quando do rollover das
chaves.

 include "/etc/bind/bind.keys";
IMPLANTANDO DNSSEC NO SERVIDOR
RECURSIVO

 Precisamos, ainda, adicionar a chave da zona raiz

ao conjunto de chaves gerenciadas do bind
(managed-keys). Para isso, editamos o arquivo
/etc/bind/bind.keys e incluímos o seguinte:
IMPLANTANDO DNSSEC NO SERVIDOR
RECURSIVO
 O próximo passo é dizer ao bind para usar a chave DLV do
ISC na validação das consultas DNS e ativar o DNSSEC.
 Para isso edite a configuração do bind que define as opções
(clausula options), no Debian esse arquivo é o
/etc/bind/named.conf.options e deve parecer com o seguinte:
IMPLANTANDO DNSSEC NO SERVIDOR
RECURSIVO

 OBS: Em versões anteriores do bind, era preciso

definir as opções dnssec-enable yes; e dnssec-
validation yes;. Porém a partir da versão 9.7.0,
elas estão habilitadas por padrão.
 Pronto, agora basta reiniciar o daemon do bind
para carregar essa nova configuração:
/etc/init.d/bind9 restart
TESTANDO A CONFIGURAÇÃO
Para testar se nosso servidor recursivo está
validando as respostas DNS, usaremos o
comando dig. Por exemplo, execute o comando
abaixo e verifique a saída.

dig +dnssec +multi @localhost www.pop-

ba.rnp.br