Por fin, RRL en BIND por defecto - con ejemplo

Historia

Al parecer este es un post que tuve que haber hecho hace mucho, sin embargo hoy recién es que lo veo funcionando correctamente


Introducción

Si el lector se parece un poco a mí, quizás sea de esas personas que tiene MUCHOS años esperando el soporte de Response Rate Limiting en Bind9. Buenas noticias!, ya existe !.


¿Qué es RRL en DNS?

RRL se refiere a Response Rate Limit. De una manera resumida es una técnica para minimizar ataques de amplificación que son muy comunes en el mundo de DNS. Hoy en día es muy recomendado en servidores autoritativos pero puede servir en recursivos.


Situación


Deseo instalar Bind9 vía apt (apt-get) y tener soporte de RRL (Response Rate Limiting). Algo que me extraña es que en teoría debería tener soporte por defecto luego del 9.10, sin embargo verán que este ejemplo está en 9.9.5)


Pasos:


El día de hoy, con Ubuntu 14.04 (si, bastante viejo) hice un upgrade de Bind9, probé RRL y todo anduvo perfecto. 

1) Actualizar bind9
   apt-get –only-upgrade install bind9

2) Chequeo la versión:
   root@my:~/SCRIPTS# apt-cache policy bind9
      bind9:
      Installed: 1:9.9.5.dfsg-3ubuntu0.19

3) Configurar RRL en bind9. Un sencillo ejemplo:


   rate-limit {
      responses-per-second 1;
   };


(favor notar que puse "1".., solo para probar que el feature realmente sirva)

4) Reiniciar bind vía rndc o el servicio (service bin9 restart)


   #service bind9 restart

Comprobar

Debido a que dejamos una sola consulta por segundo, es tan sencillo como ir a otro equipo, tener varios terminales abiertos y hacer muchos dig simultáneamente de algún dominio/zona autorizada. Si todo sale bien, en el log verás algo como:


Jul 4 11:47:55 my named[8317]: limit responses to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:55 my named[8317]: client 10.112.225.51#11257 (exp.example.com): rate limit slip response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:56 my named[8317]: client 10.112.225.51#7921 (exp.example.com): rate limit drop response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)

Mas info:
https://kb.isc.org/docs/aa-00994
https://whatis.techtarget.com/definition/DNS-amplification-attack

Aportando un grano de arena en la seguridad de la red, un caso de éxito

Introducción

Seguramente algunos de ustedes conocen el proyecto IPv6 DNS Open Resolvers [1] que lleva adelante LACNIC, un trabajo conjunto de WARP [2] y de I+D donde identificamos servidores abiertos DNS con direccionamiento IPv6.
Tradicionalmente no ofrecemos soporte de ningún tipo para la infraestructura de nuestros asociados, esto quiere decir que LACNIC “no toca” los equipos (servidores, dispositivos de red). Sin embargo siempre hemos extendido una mano de apoyo para colaborar en todo lo que podamos.

Contexto

Luego de haber identificado una dirección IPv6 donde se encuentra una servidor DNS recursivo abierto, envíamos un correo automatizado a la organización dueña de la dirección IP alertando la situación. En él explicamos las posibles consecuencias y recomendamos una serie de configuraciones para los servidores más usados. Dicho correo tiene un formato similar a:

===
DATE DD-MM-AAAA


Dear ORG-ID NAME. (OR-ID-LACNIC):

You appear to be running a DNS - open recursive resolver at IP address 280X:XXXX:X:XXXX:XXXX:XXXX:XXXX:XXXX.

It may have undesirable consequences on the Internet because it may participate in an attack against a selected target, causing a Denial of Service (DOS) attack. It generates large UDP responses to spoofed queries, with those responses becoming fragmented because of their size.

We strongly recommend to reconfiguring your resolver. Here are some ways that may help you:


- To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query";)

options {

 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of options


- To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone)

zone "example.com"{
 type master;
 file "example.com.db";
 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of zone example.com


In unbound you can achieve the same behavior with the access-control statement in the unbound.conf file. Would be something like:

server:
 access-control: 2001:db8::/32 allow


If you are an ISP, please also look at your network configuration and make sure that you do not allow spoofed traffic (that pretends to be from external IP addresses) to leave the network. Hosts that allow spoofed traffic make possible this type of attack.

References:
More information on this type of attack and what each party can do to mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A


Best regards,

LACNIC's WARP Team

=======

Caso de éxito

Queremos presentarles este caso de éxito que comenzó cuando una organización recibió el correo indicado anteriormente y se contactó con WARP buscando recibir apoyo para aplicar las recomendaciones de seguridad en sus equipos. Por ser un proyecto nuevo no nos había ocurrido esta situación anteriormente pero analizamos el caso decidimos proseguir por dos razones:
⋅⋅1. La persona que nos contactó se mostró realmente interesada
⋅⋅2. El OS y el servidor DNS se encontraba en el grupo de los cuales tenemos experiencia

Comenzamos por identificar dónde estaban los archivos de configuración del servidor y los ACLs que él mismo utilizaba. Luego le guiamos para implementar en la configuración existente, las recomendaciones de seguridad genéricas que enviamos en el correo inicial.

La buena noticia fue que el miembro de LACNIC, siempre se mostró muy dado a recibir nuestra ayuda y la comunicación fue muy fluida en todo momento. Al cabo de menos de dos semanas, con aproximadamente 8 correos intercambiados, el servidor que era una potencial amenaza se encontraba configurado de tal manera que solo permitía consultas DNS desde sus propios prefijos.
Pero esto no fue todo, la alerta que enviamos y por la cual fuimos contactados, refería solo a uno de los servidores administrados por esta organización. Para completar nuestra tarea, nuestro miembro identificó que otro servidor de su red se encontraba en las mismas condiciones que el anterior, por lo que también colaboramos en la aplicación de las correcciones necesarias.

El caso lo consideramos muy exitoso por ser servidores que tienen direcciones IPv6 estáticas las cuales eventualmente podrían ser descubiertas por algunos atacantes y traer consigo eventuales tareas maliciosas sobre la red.

Lo anterior no quiere decir que sea el único caso de éxito ocurrido, muy posiblemente otros operadores han tomado acciones sobre sus servidores sin conocimiento alguno de LACNIC. Prontamente estaremos trabajando en identificar estos casos y publicaremos algunos resultados.

Referencias

[1] (https://labs.lacnic.net/Identificando-servidores-DNS-IPv6-Open-Resolvers/)
[2] (https://warp.lacnic.net/)

Por:

Darío Gómez

Security Analyst at LACNIC WARP

@daro_ua

y

Alejandro Acosta

@ITandNetworking

Google DNS --- Averiguando cual Cluster estas utilizando

(this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on 

August 23). 

This post is being posted with his explicit permission.

I sent this out on the outage list, with a lots of good feedback sent to 

me. So I 

figured it would be useful to share the information on nanog as well.

A couple months ago had to troubleshoot a google DNS issue with Google’s 

NOC. Below 

is some helpful information on how to determine which DNS Cluster you are 

going to.

Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 

and 8.8.4.4. 

Anycast routes your DNS queries to the closes DNS cluster based on the 

best route / 

lowest metric to 8.8.8.8/8.8.4.4.   Google has deployed multiple DNS 

clusters across 

the world and each DNS Cluster has multiple servers.

So a DNS query in Chicago will go to a different DNS clusters than queries 

from a 

device in Atlanta or New York.


How to get a list of google DNS Cluster’s.
dig -t TXT +short locations.publicdns.goog. @8.8.8.8

How to print this list in a table format. 

Script from: https://developers.google.com/speed/public-dns/faq
---------------
#!/bin/bash
IFS="\"$IFS"
for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8)
do
  case $LOC in
    '') : ;;
    *.*|*:*) printf '%s ' ${LOC} ;;
    *) printf '%s\n' ${LOC} ;;
  esac
done
---------------

Which will give you a list like below. This is all of the IP network’s 

that google

uses for their DNS Clusters and their associated locations.

74.125.18.0/26 iad
74.125.18.64/26 iad
74.125.18.128/26 syd
74.125.18.192/26 lhr
74.125.19.0/24 mrn
74.125.41.0/24 tpe
74.125.42.0/24 atl
74.125.44.0/24 mrn
74.125.45.0/24 tul
74.125.46.0/24 lpp
74.125.47.0/24 bru
74.125.72.0/24 cbf
74.125.73.0/24 bru
74.125.74.0/24 lpp
74.125.75.0/24 chs
74.125.76.0/24 cbf
74.125.77.0/24 chs
74.125.79.0/24 lpp
74.125.80.0/24 dls
74.125.81.0/24 dub
74.125.92.0/24 mrn
74.125.93.0/24 cbf
74.125.112.0/24 lpp
74.125.113.0/24 cbf
74.125.115.0/24 tul
74.125.176.0/24 mrn
74.125.177.0/24 atl
74.125.179.0/24 cbf
74.125.181.0/24 bru
74.125.182.0/24 cbf
74.125.183.0/24 cbf
74.125.184.0/24 chs
74.125.186.0/24 dls
74.125.187.0/24 dls
74.125.190.0/24 sin
74.125.191.0/24 tul
172.217.32.0/26 lhr
172.217.32.64/26 lhr
172.217.32.128/26 sin
172.217.33.0/26 syd
172.217.33.64/26 syd
172.217.33.128/26 fra
172.217.33.192/26 fra
172.217.34.0/26 fra
172.217.34.64/26 bom
172.217.34.192/26 bom
172.217.35.0/24 gru
172.217.36.0/24 atl
172.217.37.0/24 gru
173.194.90.0/24 cbf
173.194.91.0/24 scl
173.194.93.0/24 tpe
173.194.94.0/24 cbf
173.194.95.0/24 tul
173.194.97.0/24 chs
173.194.98.0/24 lpp
173.194.99.0/24 tul
173.194.100.0/24 mrn
173.194.101.0/24 tul
173.194.102.0/24 atl
173.194.103.0/24 cbf
173.194.168.0/26 nrt
173.194.168.64/26 nrt
173.194.168.128/26 nrt
173.194.168.192/26 iad
173.194.169.0/24 grq
173.194.170.0/24 grq
173.194.171.0/24 tpe
2404:6800:4000::/48 bom
2404:6800:4003::/48 sin
2404:6800:4006::/48 syd
2404:6800:4008::/48 tpe
2404:6800:400b::/48 nrt
2607:f8b0:4001::/48 cbf
2607:f8b0:4002::/48 atl
2607:f8b0:4003::/48 tul
2607:f8b0:4004::/48 iad
2607:f8b0:400c::/48 chs
2607:f8b0:400d::/48 mrn
2607:f8b0:400e::/48 dls
2800:3f0:4001::/48 gru
2800:3f0:4003::/48 scl
2a00:1450:4001::/48 fra
2a00:1450:4009::/48 lhr
2a00:1450:400b::/48 dub
2a00:1450:400c::/48 bru
2a00:1450:4010::/48 lpp
2a00:1450:4013::/48 grq

There are
IPv4 Networks: 68
IPv6 Networks: 20
DNS Cluster’s Identified by POP Code’s: 20

DNS Clusters identified by POP Code to City, State, or Country. Not all of 

these are 

Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). 

https://peering.google.com/#/infrastructure and 

https://www.google.com/about/datacenters/inside/locations/

Most of these are airport codes, it did my best to get the location correct.
iad          Washington, DC
syd         Sydney, Australia
lhr          London, UK
mrn        Lenoir, NC
tpe         Taiwan
atl          Altanta, GA
tul          Tulsa, OK
lpp          Findland
bru         Brussels, Belgium
cbf         Council Bluffs, IA
chs         Charleston, SC
dls          The Dalles, Oregon
dub        Dublin, Ireland
sin          Singapore
fra          Frankfort, Germany
bom       Mumbai, India
gru         Sao Paulo, Brazil
scl          Santiago, Chile
nrt          Tokyo, Japan
grq         Groningen, Netherlans



Which Google DNS Server Cluster am I using. I am testing this from 

Chicago, IL

# dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
"173.194.94.135"                     <<<<<dig o-o.myaddr.l.google.com -t 

txt +short @8.8.8.8

"74.125.42.138" "173.194.102.132" "74.125.177.5" "74.125.177.74" "74.125.177.71" 

"74.125.177.4" Which all are Google DNS Networks in Atlanta. 74.125.42.0/24 atl 

 74.125.177.0/24 atl 172.217.36.0/24 atl 173.194.102.0/24 atl 2607:f8b0:4002::/48 atl

 Just thought it would be helpful when troubleshooting google DNS issues.

(one more time: this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing 

list on August 23). This post is being posted with his explicit permission.

$GENERATE usando registros A en BIND. Match forward y rDNS

Hola,
  Este post es muy corto pero quizas muy util. Hay menos documentacion en Internet que la esperada.

Objetivo:
  a) Configurar los DNS reversos y los DNS forward de una red /24 en BIND9 utilizando $GENERATE.
 b) Que coincida la resolucion forward a la resolucion reversa

Requisitos:
  - Una red /24 (claro, el ejemplo se puede ajustar a otras redes)
  - BIND9
  - Usaremos registros A y PTR

Ejemplo:
  La red 192.168.30.0/24
  Dominio:  ejemplo.com

  Vamos a hacer que los reversos de 192.168.30.X resuelvan a: X.cliente.ejemplo.com
  De igual manera, X.cliente.ejemplo.com resolverá a 192.168.30.X

  Sería así:
  192.168.30.1 ---> 1.cliente.ejemplo.com
  192.168.30.2 ---> 2.cliente.ejemplo.com
  192.168.30.3 ---> 3.cliente.ejemplo.com
  1.cliente.ejemplo.com ---> 192.168.30.1
  2.cliente.ejemplo.com ---> 192.168.30.2
  3.cliente.ejemplo.com ---> 192.168.30.3
  (etc)

Pasos:
   Creamos la zona reversa en /etc/bind/named.conf.

a) La zona reversa:

zone "30.168.192.in-addr.arpa" {
     type master;
     file "30.168.192.in-addr.arpa.db";
     allow-query { any; };
};


Luego en el archivo 30.168.192.in-addr.arpa.db  colocamos lo siguiente:

$TTL    86400 ; 24 hours, could have been written as 24h or 1d
@  1D  IN        SOA localhost.     hostmaster.ejemplo.com. (
                              2002022401 ; serial
                              3H ; refresh
                              15 ; retry
                              1w ; expire
                              3h ; minimum
                             )
; Name servers for the zone - both out-of-zone - no A RRs required
                        NS      localhost.

$GENERATE 1-255 $ PTR $.cliente.ejemplo.com.


b) La zona forward, utilizando registros A es:

$TTL    86400 ; 24 hours, could have been written as 24h or 1d
@  1D  IN        SOA localhost.     hostmaster.ejemplo.com. (
                              2002022401 ; serial
                              3H ; refresh
                              15 ; retry
                              1w ; expire
                              3h ; minimum
                             )
; Name servers for the zone - both out-of-zone - no A RRs required
                        NS      localhost.

$GENERATE 1-255.cliente.ejemplo.com $ A 192.168.30.$



Pruebas:
Para probar:
#dig -x 192.168.30.3  (reverso dns)
#dig 3.cliente.ejemplo.com  (forward dns)


Espero haya sido de utilidad
 

Bind / Syslog / Logrotate

Situacion:
Deseo que Bind envie los logs a traves de Syslog y luego rotarlos diariamente con logrotate.

Solucion:
Para lograr que Bind envie sus logs a traves de Syslog recomiendo seguir los siguientes pasos:

1) Definir un nuevo facility en /etc/syslog.conf el cual utilizaremos como "canal" dentro de Bind. Esto es muy conveniente para tener un unico archivo con solo informacion relevante sobre DNS y Bind. Para definir el facility coloca lo siguiente dentro de /etc/syslog.conf

local7.* -/var/log/bind.log

NOTA: Recuerda que puedes definir desde local0 hasta local7 facities segun tu necesidad

2) Luego en Bind se le va a indicar que utilice el facity local7 y guarde los logs de query (en mi caso es lo unico que necesito, se puede almacenar gran cantidad de logs referentes a otros temas como: lame servers, dnssec, xfer y mucho mas). Ademas de almacenar el query deseo que se escriba la fecha y hora del query DNS. En /etc/named.conf (seccion de options) agrega:

logging {
channel query.log {
severity debug 3;
print-time yes;
syslog local7;
};
category queries { query.log; };
};

3) Debido al tamano del logs, posteriormente tuve la necesidad de rotarlo de manera diaria pero antes deseo realizar la rotacion deseaba ejecutar un script para un proceso puntual. Para ello hice la siguiente configuracion en logrotate. Para este punto editar el archivo /etc/logrotate.d/bind y anadir:

/var/log/bind.log {
daily
prerotate
/root/SCRIPTS/dnsqueries.sh
endscript
missingok
rotate 4
compress
create
}

Con este paso, el archivo /var/log/bind.log se rotara automaticamente de manera diaria pero antes se ejecutara el script /root/SCRIPTS/dnsqueries.sh.

Mas informacion:
http://zytrax.com/books/dns/ch7/logging.html (DNS Bind Logging)
http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm (The Unix system log)

Suerte, espero haya sido util,

Herramienta en linea gratis para configurar reversos de IPv6

Situacion:
El dia de ayer tuve la necesidad de configurar los reversos de un prefijo IPv6 en mis servidores Bind; honestamente era la primera vez que tenia que hacer dicha tarea y por ello recurri a nuestro buen amigo google

Solucion:
En fin, luego de realizar una pequena busqueda consegui la siguiente herramienta en linea y gratuita que decidi compartirla con ustedes debido a que es excelente: http://www.fpsn.net/tools&tool=ipv6-inaddr. La herramienta es un "constructor de reversos IPv6"
La herramienta es muy sencilla de utilizar, la misma te hace las preguntas de: a) prefijo IPv6, b) email del responsable de la zona, c) servidor DNS primario y secundario y d) las direcciones IPv6 a las cuales deseas crearle el nombre.
Lo interesante de la herramienta es que te genera tanto el codigo a colocar dentro del named.conf como el del archivo de zona. Luego solo tienes que hacer copy/paste.
Les dejo otra vez el link: http://www.fpsn.net/tools&tool=ipv6-inaddr
Probar conexiones IPv6: http://acostanetwork.blogspot.com/2009/04/probar-ipv6.html y http://www.whatismyipv6.co

Luego de utilizar la herramienta todo funciono perfecto!!

Implementar DNSSEC sobre Linux. Solo resolver

*** POST OBSOLETO ****
*** FAVOR LEER LA VERSION 2 ***

Problema:
Montar un servidor DNS solo como resolver, es decir, sin funcionar como servidor autorizado para ciertas zonas


Que se necesita:
- Servidor Linux
- Bind 9.3 o superior (en mi caso utilicé 9.6)


Alcance
- Vamos a validar todo lo que sea .br
- Vamos a validar todo lo que sea udp53.org

Procedimiento:
1) Instalar bind en un servidor Linux. En mi caso utilizo Mandriva y con un sencillo urpmi bind fue suficiente. Es importante destacar que para que DNSSEC ande se necesita tener instalado openssl y sus librerias. Actualmente la inmensa mayoría de las distribuciones ya viene con openssl

2) En /var/named.conf se necesita:
options {
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside "." trust-anchor dlv.isc.org.;
};

La primera opción permite dnssec para las zonas autorizadas y la segunda opción para realizar recursividad utilizando DNSSEC. La tercera opción la veremos con detalle más adelante.


3) Es necesario obtener las llaves públicas de los registros .br y udp53.org (que son los dominios que queremos verificar en este momento). Para ello:

[root@localhost etc]# dig br DNSKEY

{...}

br. 21502 IN DNSKEY 257 3 5 AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PM Npyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/ 6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+D P/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=

{...}


[root@localhost etc]# dig udp53.org DNSKEY

{...}

udp53.org. 5882 IN DNSKEY 257 3 5 BEAAAAMKj6IGc8E/bBW7i6zDGgnKUXwamtR9PlFiuTg0/oa4i1okCg4J vLEq7EVpxdDi4yc1Ym9kGTUngZ59iVleoL8O5Zq+oPAPCYSbtn+ASsL6 0iCp4PJ6LV0A9d2NE/BetXO/Re/NRsSG18yFZCWGfX8mBnb2zG7Mb+0t pUuRsu9dBN31ljsbTUGmkDbqEw2xaDAUXqDGD5+pgN0NGqcPg0/HzFv9

{...}

4) Necesitamos las llaves DLV que pueden ser conseguidas en la pagina de la ISC en:
http://ftp.isc.org/www/dlv/dlv.isc.org.key.
Las llaves DLV ((DNSSEC Look-aside Validation) son un recurso adicional utilizado en aquellos servidores DNSSEC con recursividad. La idea es apoyar al conglomerado de internet en las primeras etapas de DNSSEC en el mundo

5) Vamos a copiar esas llaves obtenidas en el archivo named.conf bajo la sección trusted-keys (si no existe dicha sección en el archivo la crearemos). Por ejemplo

trusted-keys {
"br." 257 3 5
"AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJB
NmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPq
Xr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1N
GbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hN
x94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=";

"dlv.isc.org." 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";

"udp53.org." 257 3 5 "BEAAAAMKj6IGc8E/bBW7i6zDGgnKUXwamtR9PlFiuTg0/oa4i1okCg4J vLEq7EVpxdDi4yc1Ym9kGTUngZ59iVleoL8O5Zq+oPAPCYSbtn+ASsL6 0iCp4PJ6LV0A9d2NE/BetXO/Re/NRsSG18yFZCWGfX8mBnb2zG7Mb+0t pUuRsu9dBN31ljsbTUGmkDbqEw2xaDAUXqDGD5+pgN0NGqcPg0/HzFv9";

};

6) Listo!!., reiniciar el servidor named. Por ejmplo:
/etc/init.d/named restart (o con rndc, como tu desees)

Revisar que se encuentre funcionando bien

La mejor opción es utilizar el famoso comando dig y chequear el flag AD en al respuesta. Por ejemplo:

RESPUESTA SIN DNSSEC

[root@localhost etc]# dig +dnssec registro.br

; <<>> DiG 9.6.0-P1 <<>> +dnssec registro.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43771 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5



RESPUESTA CON DNSSEC

[root@localhost etc]# dig +dnssec registro.br

; <<>> DiG 9.6.0-P1 <<>> +dnssec registro.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1063 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1


Más información:
* www.isc.org/files/DNSSEC_in_6_minutes.pdf
* http://registro.br/info/dnssec.html