Introducción al servicio DNS

Introducción al servicio DNS

BIND
Servidor DNS
Soporte para base de datos
Seguridad
Instalación y configuración
Instalación
Administración del servicio
Ficheros de configuración
Estructura del fichero de configuración
Implementaciones
Almacenamiento en caché del servidor DNS
Configurar como servidor DNS de almacenamiento en caché
Forwarding DNS Server
Configurar como servidor DNS de reenvío
Bind zonas DNS
Servidor Master (primario)
Servidor Slave (secundario)
Asegurando un servidor BIND
Bind con chroot y usuario del servicio
Segurizando las actualizaciones y transferencias de zona de DNS
DNSSEC
Herramientas
checkconf
Herramienta DIG
Uso de DIG
Herramienta RNDC
Uso de RNDC

BIND

Servidor DNS
BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet Name Daemon) es el
servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Unix, en los
cuales es un estándar de facto. Es patrocinado por la Internet Systems Consortium. BIND fue
creado originalmente por cuatro estudiantes de grado en la University of California, Berkeley y
liberado por primera vez en el 4.3BSD. Paul Vixie comenzó a mantenerlo en 1988 mientras
trabajaba para la DEC.

Una nueva versión de BIND (BIND 9) fue escrita desde cero en parte para superar las dificultades
arquitectónicas presentes anteriormente para auditar el código en las primeras versiones de
BIND, y también para incorporar DNSSEC (DNS Security Extensions). BIND 9 incluye entre otras
características importantes: TSIG, notificación DNS, nsupdate, IPv6, rndc flush, vistas,
procesamiento en paralelo, y una arquitectura mejorada en cuanto a portabilidad. Es
comúnmente usado en sistemas GNU/Linux.
Soporte para base de datos

Las versiones anteriores de BIND no ofrecen ningún mecanismo para almacenar y recuperar
datos del sitio en diferentes condiciones en archivos de texto plano. Desde la versión 9,4 de BIND,
DLZ ha estado disponible como una opción que permite tiempo de compilación para el
almacenamiento del sitio en una gran variedad de formatos de bases de datos como por ejemplo
LDAP, Berkeley DB, PostgreSQL, MySQL u ODBC.

Seguridad

Como otras herramientas que estuvieron presentes desde los primeros días de Internet, BIND 4 y
BIND 8 han tenido un gran número de vulnerabilidades de seguridad a lo largo del tiempo. BIND
9, habiéndose reescrito, tiene un historial mucho mejor en cuanto a este tema, aunque es común
que se sigan encontrando problemas de seguridad tanto en las versiones actuales como las
anteriores.

Instalación y configuración
Instalación

Debian

# apt update && apt install bind9 bind9utils

CentOS

# yum install bind bind-utils

Administración del servicio

CentOS

Activar servicio al inicio del sistema.

# systemctl enable named

Recargar ficheros de configuración

# systemctl reload named

Estado del servicio

# systemctl status named

Debian

Activar servicio al inicio del sistema.

# systemctl enable bind9

Recargar ficheros de configuración

# systemctl reload bind9

Estado del servicio

# systemctl status bind9

Ficheros de configuración

CentOS

El archivo principal de configuración de bind es /etc/[Link] mientras que los ficheros de

zona los encontramos en /var/named/bind .

Debian

En el caso de Debian el archivo principal es /etc/bind/[Link] :

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/[Link] for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/[Link]

include "/etc/bind/[Link]";
include "/etc/bind/[Link]";
include "/etc/bind/[Link]-zones";

Los includes nos indican que la configuración esta divida en 3 ficheros.

Fichero [Link] :

options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want

// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See [Link]

// If your ISP provided one or more IP addresses for stable

// nameservers, you probably want to use them as forwarders.  
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

// forwarders {
// [Link];
// };

//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See [Link]
 //========================================================================
dnssec-validation auto;

listen-on-v6 { any; };
};

Fichero [Link] :

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Fichero [Link]-zones :

// prime the server with knowledge of the root servers

zone "." {
type hint;
file "/usr/share/dns/[Link]";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
type master;
file "/etc/bind/[Link]";
};

zone "[Link]" {
type master;
file "/etc/bind/db.127";
};

zone "[Link]" {
type master;
file "/etc/bind/db.0";
};

zone "[Link]" {
type master;
file "/etc/bind/db.255";
};

Estructura del fichero de configuración

Las declaraciones van entre llaves y se terminan con un punto y coma.

Las directivas en las declaraciones también terminan con un punto y coma.

 declaración {
directiva;
};

Implementaciones
Almacenamiento en caché del servidor DNS

La primera configuración será para un servidor DNS de almacenamiento en caché. Este tipo de
servidor también se conoce como solucionador porque maneja consultas recursivas y
generalmente puede manejar el trabajo pesado de rastrear datos DNS de otros servidores.

Cuando un servidor DNS de almacenamiento en caché rastrea la respuesta a la consulta de un

cliente, devuelve la respuesta al cliente. Pero también almacena la respuesta en su caché durante
el período de tiempo permitido por el valor TTL de los registros. La memoria caché se puede
utilizar como fuente para solicitudes posteriores con el fin de acelerar el tiempo total de ida y
vuelta.

Casi todos los servidores DNS que pueda tener en su configuración de red almacenarán
servidores DNS en caché. Estos compensan la falta de bibliotecas de resolución de DNS
adecuadas implementadas en la mayoría de las máquinas cliente. Un servidor DNS de
almacenamiento en caché es una buena opción para muchas situaciones. Si no desea depender
del DNS de su ISP u otros servidores DNS disponibles públicamente, crear su propio servidor de
almacenamiento en caché es una buena opción. Si está muy cerca físicamente de las máquinas
cliente, también es muy probable que mejore los tiempos de consulta de DNS.

Configurar como servidor DNS de almacenamiento en caché

Primero, cubriremos cómo configurar Bind para que actúe como un servidor DNS de
almacenamiento en caché. Esta configuración obligará al servidor a buscar respuestas de forma
recursiva de otros servidores DNS cuando un cliente emita una consulta. Esto significa que está
haciendo el trabajo de consultar cada servidor DNS relacionado por turnos hasta que encuentre
la respuesta completa.

Los archivos de configuración de Bind se guardan de forma predeterminada en un directorio en /

etc / bind.

Para configurar el almacenamiento en caché, el primer paso es configurar una lista de control de
acceso o ACL.

Como servidor DNS que se utilizará para resolver consultas recursivas, no queremos que
usuarios malintencionados abusen del servidor DNS. Un ataque llamado ataque de amplificación
de DNS es especialmente problemático porque puede hacer que su servidor participe en ataques
distribuidos de denegación de servicio.

Un ataque de amplificación de DNS es una forma en que los usuarios malintencionados intentan
derribar servidores o sitios en Internet. Para ello, intentan encontrar servidores DNS públicos que
resuelvan consultas recursivas. Ellos falsifican la dirección IP de la víctima y envían una consulta
que devolverá una gran respuesta al servidor DNS. Al hacerlo, el servidor DNS responde a una
pequeña solicitud con una gran carga útil dirigida al servidor de las víctimas, amplificando
efectivamente el ancho de banda disponible del atacante.
Alojar un servidor DNS público recursivo requiere una gran cantidad de configuración y
administración especiales. Para evitar la posibilidad de que su servidor sea utilizado con fines
maliciosos, configuraremos una lista de direcciones IP o rangos de red en los que confiamos.

Sobre el bloque de opciones, crearemos un nuevo bloque llamado acl. Cree una etiqueta para el
grupo de ACL que está configurando. En esta guía, llamaremos al grupo buenos clientes.

/etc/bind/[Link]:

acl goodclients {
  [Link]/24;
  localhost;
  localnets;
};

options {
      directory "/var/cache/bind";
  recursion yes;
  allow-query { goodclients; };
       
      dnssec-validation auto;

      auth-nxdomain no;   # conform to RFC1035

      listen-on-v6 { any; };
};

Activamos explícitamente la recursividad y luego configuramos el parámetro allow-query para

usar nuestra especificación ACL. Podríamos haber utilizado un parámetro diferente, como allow-
recursion para hacer referencia a nuestro grupo de ACL. Si está presente y la recursividad está
activada, allow-recurssion dictará la lista de clientes que pueden utilizar servicios recursivos.

Sin embargo, si no se establece allow-recursion, entonces Bind recurre a la lista allow-query-

cache, luego a la lista allow-query y finalmente a un valor predeterminado de localnets y localhost
solamente. Dado que estamos configurando un servidor de solo almacenamiento en caché (no
tiene zonas autorizadas propias y no reenvía solicitudes), la lista de consultas permitidas siempre
se aplicará solo a la recursividad. Lo estamos usando porque es la forma más general de
especificar la ACL.

Cuando haya terminado de realizar estos cambios, guarde y cierre el archivo.

En realidad, esto es todo lo que se necesita para almacenar en caché un servidor DNS. Si decidió
que este es el tipo de servidor que desea usar, no dude en continuar para aprender cómo
verificar sus archivos de configuración, reiniciar el servicio e implementar configuraciones de
cliente.

De lo contrario, continúe leyendo para aprender a configurar un servidor DNS de reenvío.

Reenvío: sólo pasa la consulta DNS a otro servidor DNS (por ejemplo, su ISP). Los routers
domésticos utilizan el reenvío para pasar consultas DNS desde los clientes de su red doméstica a
los servidores DNS de su ISP. Por ejemplo, para [Link], un servidor DNS de reenvío
primero verificará su caché (ya hizo esta pregunta antes), y si la respuesta no está en su caché,
pediría a su reenviador (el servidor DNS de su ISP) Para la respuesta, que respondería con una
respuesta en caché, o realizaría la recursión hasta que descubriera la respuesta.
Recursividad: el servidor DNS que recibe la consulta se encarga de averiguar la respuesta a esa
consulta recursivamente consultando servidores DNS autorizados para ese dominio. Por ejemplo,
para [Link], un recursor primero consultaría a los servidores raíz para qué servidores
DNS son responsables del TLD .com, entonces pediría a esos servidores por [Link],
entonces consultaba a los servidores por [Link] para [Link], obteniendo
finalmente la respuesta a la consulta original.

En términos de seguridad, debe separar los recursores / transportistas (normalmente los

servidores DNS utilizados para dar servicio a un grupo de clientes) y los servidores DNS con
autoridad (por lo general estos son responsables SOLAMENTE para responder a las consultas
sobre los dominios con los que hacen autoridad; Consultas recursivas para cualquiera).

Forwarding DNS Server

La segunda configuración que demostraremos es un servidor DNS de reenvío. Un servidor DNS

de reenvío se verá casi idéntico a un servidor de almacenamiento en caché desde la perspectiva
de un cliente, pero los mecanismos y la carga de trabajo son bastante diferentes.

Un servidor DNS de reenvío ofrece la misma ventaja de mantener una caché para mejorar los
tiempos de resolución de DNS para los clientes. Sin embargo, en realidad no realiza ninguna
consulta recursiva. En su lugar, reenvía todas las solicitudes a un servidor de resolución externo y
luego almacena en caché los resultados para usarlos en consultas posteriores.

Esto permite que el servidor de reenvío responda desde su caché, sin que sea necesario que haga
todo el trabajo de las consultas recursivas. Esto permite que el servidor solo realice solicitudes
individuales (la solicitud del cliente reenviado) en lugar de tener que pasar por toda la rutina de
recursividad. Esto puede ser una ventaja en entornos donde la transferencia de ancho de banda
externa es costosa, donde sus servidores de almacenamiento en caché pueden necesitar ser
cambiados con frecuencia o cuando desea reenviar consultas locales a un servidor y consultas
externas a otro servidor.

Configurar como servidor DNS de reenvío

Si un servidor DNS de reenvío se adapta mejor a su infraestructura, podemos configurarlo

fácilmente.

Comenzaremos con la configuración que dejamos en la configuración del servidor de caché. El

archivo [Link] debería verse así:

acl goodclients {
       [Link]/24;
      localhost;
      localnets;
};

options {
      directory "/var/cache/bind";

      recursion yes;
      allow-query { goodclients; };

      dnssec-validation auto;

      auth-nxdomain no;    # conform to RFC1035

      listen-on-v6 { any; };
 };

Usaremos la misma lista de ACL para restringir nuestro servidor DNS a una lista específica de
clientes. Sin embargo, necesitamos cambiar la configuración para que el servidor ya no intente
realizar consultas recursivas por sí mismo.

Para hacer esto, no cambiamos la recursividad a no. El servidor de reenvío sigue proporcionando
servicios recursivos respondiendo consultas de zonas para las que no tiene autoridad. En su
lugar, necesitamos configurar una lista de servidores de almacenamiento en caché a los que
reenviar nuestras solicitudes.

Esto se hará dentro del bloque de opciones {}. Primero, creamos un bloque dentro llamado
reenviadores que contiene las direcciones IP de los servidores de nombres recursivos a los que
queremos reenviar solicitudes. En nuestra guía, usaremos los servidores DNS públicos de Google
([Link] y [Link]):

. . .

options {
      directory "/var/cache/bind";

      recursion yes;
      allow-query { goodclients; };

      forwarders {
               [Link];
               [Link];
      };
      . . .

Posteriormente, deberíamos establecer la directiva de reenvío en "solo", ya que este servidor

reenviará todas las solicitudes y no debería intentar resolver las solicitudes por sí solo.

El archivo de configuración se verá así cuando haya terminado:

. . .

options {
      directory "/var/cache/bind";

      recursion yes;
      allow-query { goodclients; };

      forwarders {
               [Link];
               [Link];
      };
      forward only;

      dnssec-validation auto;

      auth-nxdomain no;    # conform to RFC1035

      listen-on-v6 { any; };
};
Bind zonas DNS

Para que un servidor sea máster primario de una zona debe tener la misma declarada en el
archivo.

Fichero [Link] .

zone "[Link]" {
      type master;
      file "/etc/bind/[Link]";
};

Fichero [Link] .

;
; BIND data file for local loopback interface
;
$ORIGIN [Link].
$TTL 604800
@ IN SOA [Link]. [Link]. (
    2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; IP del host '[Link]'
@ IN A [Link]
; Servidores de delegación
[Link]. IN NS [Link].
[Link]. IN NS [Link].

; Registros NS
ns1 IN A [Link]
ns2 IN A [Link]

La directiva $ORIGIN sirve para agregar un dominio a los nombres de dominio incompletos.
Un nombre se considera incompleto (o relativo) si no tiene un punto al final.
$TTL define el tiempo de vida predeterminado para cada registro sin dicho parámetro
declarado.
Elcarácter ; convierte el texto que está a la derecha en la misma línea en comentario.
Cada línea situada a continuación contiene un RR, es decir un registro de recurso.
Cada registro tiene de izquierda a derecha, el dominio (o nombre completo del host) en el
cual se encuentra el RR, el TTL (es opcional) la clase de RR (que a menos que que se use
Chaosnet o Hesiod es IN), y los datos del recurso.
La arroba "@" significa en estos casos el nombre de la zona terminado con un punto.

Servidor Master (primario)

Es el servidor con autoridad donde se mantiene la copia principal de los datos de la zona.

Este servidor se basa en la directiva allow-transfer que permite la trasferencia de zonas al

servidor indicado:
 allow-transfer { [Link]; }; # slave server ip

Tal directiva se especifica dentro de la sección options o la seccion zone , en el caso de la

sección options se entiende como global y todas las zonas se trasfieren.

La declaración de zona tiene el siguiente aspecto:

zone "[Link]" {
      type master; # se indica que esta esta zona es del tipo "master"
      file "/etc/bind/[Link]";
}

Servidor Slave (secundario)

Es el servidor secundario, el cual carga el contenido de la zona copiándolo (generalmente) desde

un servidor Master Primario. Esta operación se denomina transferencia de zona.

En el caso de un servidor secundario se deshabilita la transferencia de zonas, este no envía sus

zonas a ningún otro servidor:

allow-transfer { none; };

Se declara la zona en el servidor secundario indicando el nombre de fichero de registros y desde

donde obtenerlo:

zone "[Link]" {
      type slave;
      file "[Link]";
masters { [Link]; }; # desde que servidor va a trasferir la zona.
};

Asegurando un servidor BIND

Bind con chroot y usuario del servicio

Ejecutar bind con chroot agrega una capa de seguridad adicional al hacer que el servicio se
ejecute en un directorio "jaula". El entorno chroot deberá contar los archivos especiales tales
como /dev/zero , /dev/random , /etc/localtime , y de acuerdo a la distribución, /etc/passwd ,
/dev/null , etc.

Instalación en CentOS

# yum install bind-chroot

Luego detenemos el servicio ordinario y arrancamos el servicio enjaulado:

# systemctl stop named && systemctl start named-chroot

# systemctl status named
 [Link] - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/[Link]; disabled)
Active: inactive (dead)
sep 29 02:05:11 [Link] named[13252]: running
sep 29 02:05:11 [Link] named[13252]: zone [Link]/IN: sending
notifies (s...0)
sep 29 02:05:11 [Link] systemd[1]: Started Berkeley Internet Name
Domain (DNS).
sep 29 02:05:34 [Link] systemd[1]: Stopping Berkeley Internet Name
Domain (DNS)...
sep 29 02:05:34 [Link] named[13252]: received control channel
command 'stop'
sep 29 02:05:34 [Link] named[13252]: shutting down: flushing
changes
sep 29 02:05:34 [Link] named[13252]: stopping command channel on
[Link]#953
sep 29 02:05:34 [Link] named[13252]: no longer listening on
[Link]#53
sep 29 02:05:34 [Link] named[13252]: exiting
sep 29 02:05:34 [Link] systemd[1]: Stopped Berkeley Internet Name
Domain (DNS).
Hint: Some lines were ellipsized, use -l to show in full.

Puntos de montaje

TARGET SOURCE FSTYPE OPTIONS

/ /dev/mapper/centos-root xfs rw,relatime,attr2,inode64,noquota
/var/named/chroot/etc/named /dev/mapper/centos-root[/etc/named] xfs
rw,relatime,attr2,inode64,noquota
/var/named/chroot/etc/[Link] /dev/mapper/centos-root[/etc/[Link]]
xfs
rw,relatime,attr2,inode64,noquota
/var/named/chroot/etc/[Link] /dev/mapper/centos-root[/etc/[Link]] xfs
rw,relatime,attr2,inode64,noquota
/var/named/chroot/etc/[Link] /dev/mapper/centos-
root[/etc/[Link]] xfs
rw,relatime,attr2,inode64,noquota
/var/named/chroot/etc/[Link] /dev/mapper/centos-root[/etc/[Link]] xfs
rw,relatime,attr2,inode64,noquota
/var/named/chroot/usr/lib64/bind /dev/mapper/centos-root[/usr/lib64/bind] xfs
rw,relatime,attr2,inode64,noquota
/var/named/chroot/etc/[Link] /dev/mapper/centos-
root[/etc/[Link]] xfs
rw,relatime,attr2,inode64,noquota
/var/named/chroot/var/named /dev/mapper/centos-root[/var/named] xfs
rw,relatime,attr2,inode64,noquota

Y un detalle muy importante:

# ps aux | grep named | grep -v grep

named 13319 0.0 0.8 242468 16716 ? Ssl 02:05 0:00 /usr/sbin/named -u named -t
/var/named/chroot -4

Podemos ver los archivos existentes en la jaula:

 # tree /var/named/chroot/

El servicio se ejecuta con la opción -t indicando el directorio en el cual usuario named está
limitado.
Los archivos se editan como si el chroot no existiera, es decir es (casi) transparente. Decimos casi
porque al modificar un archivo, el editor debe hacer una copia y hacer las modificaciones el
archivo original. De otra manera, el cambio no se verá reflejado en la jaula.

Esto se logra en vim de la siguiente manera, por ejemplo para editar el archivo [Link]:

# vi -c "set backupcopy=yes" /etc/[Link]

Asimismo, es importante señalar

# grep named /etc/passwd

named:x:25:25:Named:/var/named:/sbin/nologin

Segurizando las actualizaciones y transferencias de zona de DNS

BIND 9 soporta dos métodos alternativos de garantizar a los clientes el derecho a desarrollar
actualizaciones dinámicas a una zona, configurado mediante las opciones allow-update
y update-policy , respectivamente.

La directiva allow-update otorga el permiso para actualizar cualquier registro de cualquier

nombre en la zona. La directiva update-policy permite un control más granular sobre las
actualizaciones que se permiten.

Al usar la directiva update policy local se puede usar el comando nsupdate -l el cuál permite
enviar solicitudes de actualización el DNS del propio host, y firmarlas usando la clave de la sesión.
Esta es una clave de sesión TSIG , de manera predeterminada su ruta es
/var/run/named/[Link] .

TSIG usa claves secretas compartidas y un hash unidireccional para proporcionar medios seguros
criptográficamente de identificar cada extremo de una conexión mientras se permite hacer o
responder a una actualización de DNS. De esta manera se pueden autenticar las solicitudes y
viajar por la Internet.

Es importante el uso de NTP ya que TSIG usa las marcas de tiempos para impedir que las
respuestas sean usadas por un atacante.

Primer paso

Generamos un par de claves con el algoritmo criptográfico HMAC-SHA256 de 128 bits con el tipo de
nombre asociado HOST. Le ponemos el nombre descrito a cada clave de máster-slave.

# dnssec-keygen -a hmac-sha256 -b 128 -n HOST master-slave

Kmaster-slave.+163+05300
# ls -ltr
total 8
-rw------- 1 root root 168 oct 3 14:33 Kmaster-slave.+163+[Link]
-rw-r--r-- 1 root root 56 oct 3 14:33 Kmaster-slave.+163+[Link]
En este caso se generaron entonces 2 claves, una privada Kmaster-slave.+163+[Link] y
una clave pública Kmaster-slave.+163+[Link] .

[Link] es el nombre de la clave

163 es la representación numérica del algoritmo
05300 es el identificador de la clave

Segundo paso

Creamos el archivo /etc/named/[Link] :

key master-slave. {
algorithm hmac-sha256;
secret "OadNk8cDlMnRrUT432rKdw==";
};

Se debe hacer que dueño de estos archivos sea el usuario con el que corre bind.

La clave compartida se saca del archivo de la clave privada:

# cat Kmaster-slave.+163+[Link]
Private-key-format: v1.3
Algorithm: 163 (HMAC_SHA256)
Key: OadNk8cDlMnRrUT432rKdw==
Bits: AAA=
Created: 20141003174055
Publish: 20141003174055
Activate: 20141003174055

Y luego agregamos una directiva include en /etc/[Link] :

...
include "/etc/named/[Link]";
...

Tercer paso

Añadimos en /etc/[Link] lo siguiente:

...
server [Link] {
keys { master-slave. ;};
};

Esto es para pedirle al DNS en [Link] que utilice la key master-slave .

Cuarto paso

Modificamos la directiva allow-transfer para que permita solamente la transferencia si el

servidor slave conoce la clave master-slave .
 zone "[Link]" IN {
type master;
file "[Link]";
allow-transfer { key master-slave. ; };
};

Quinto paso

...
server [Link] {
keys { master-slave. ;};
};
zone "[Link]" IN {
type slave;
masters { [Link] ; };
file "slaves/[Link]";
allow-notify { key master-slave. ; };
};
include "/etc/named/[Link]";

Sexto paso

Reiniciamos el servicio bind tanto en el máster como en el slave.

# systemctl -l reload named

DNSSEC

En el servicio DNS tradicional no hay nada que garantice que la respuesta que recibe un cliente
sea del servidor legítimo. DNSSEC es un conjunto de extensiones que intenta solucionar ese
problema.

Con DNSSEC si una respuesta es manipulada, el cliente recibirá un SERVFAIL .

DNSSEC usa RR's adicionales los cuales son explicados en la siguiente tabla:
 RR Contiene Sirve para

Verificar la firma con

una clave pública,
RRSIG Datos de la firma de DNSSSEC-bis
almacenada en un
registro DNSKEY

Verificar las firmas

DNSKEY Clave pública asociada DNSSEC en los registros
RRSIG

Hash de la clave pública asociado con una El proceso de

DS
zona firmada DNS autenticación

El siguiente nombre de dominio que contiene

Verificar que un
los datos autoritativos o un punto de
conjunto de RRs no
NSEC delegación (conjunto de RRs NS ) y el conjunto
existe en la zona
de RR presentes en el nombre de dominio
existencia
correspondiente al RR NSEC

NSEC3 Id. ant. pero hasheados criptográficamente Id. ant

Usado por otros

servidores DNS para
El RR NSEC3PARAM contiene los parámetros
para elegir un conjunto
NSECPARAM NSEC3 necesarios para calcular los nombres
apropiado de RRs NSEC
de dominio donde se encuentran los RR
para respuestas
negativas

Un RR DS apunta a un DNSKEY al almacenar la marca de la clave, el número del algoritmo, y

el resultado de un hash aplicado sobre el RR DNSKEY . Al almacenar el registro DS , un cliente
DNS puede autenticar el RR DNSKEY al cual el DS apunta.
El RR DS y su correspondiente RR DNSKEY tiene el mismo nombre del dominio al que
corresponde, pero se almacenan en diferentes lugares. El RR DS aparece solamente en el
padre, y tiene datos autoritativos en la zona padre. Por ejemplo, el RR DS para
[Link] se almacena en la zona "com" en lugar de [Link] . El RR DNSKEY se
almacena en [Link] . Esto simplifica la gestión y firmado de la zona pero introduce un
proceso de respuesta especial para el RR DS .
Cuando se usa DNSSEC , cada respuesta a una consulta DNS contiene un registro DNS RRSIG ,
además del tipo de registro que fue solicitado.

Crear un DNS seguro involucra los siguientes pasos:

1. Generación de par de claves para la zona

2. Generación de KSK (Key Signing Keys las cuales se usan para firmar otros registros DNSKEY).
3. Agregar las claves públicas al archivo de zona.
4. Firmar la zona con la herramienta dnssec-signzone .
5. Editar el archivo [Link] para que tome el nuevo archivo de zona firmado con la
extensión .signed .
6. Reiniciar el servicio.

Luego se puede verificar la zona firmada mediante la herramienta dig:

# dig @[Link] [Link] mx +dnssec +short

 10 [Link].
5 [Link].
MX 5 2 86400 20141101175827 20141002175827 6087 [Link].
ED3VSmIcancibzkwDQstAttK/GtXYp8C0wAyUOWa4kkk/Q0fJStfTrjU
I5mLeFCoMG9oBgUvPTJqPzln1AG8fJPmFELO4QsV33NShVQG2L4yPIgs
yUPTVUkSoPkZux1R3L3XrqLS8vGAzk7abmRTXd3Izh8oG+/N4Lm0PRGB QEU=

$ dig @[Link] [Link] soa +dnssec +short

[Link]. [Link]. 2001062502 21600 3600 604800 86400
SOA 5 2 86400 20141101175827 20141002175827 6087 [Link].
oHD32yebUPLtK0J9RE+n2AvhtEutRCWUKaJ/lEfAYfniAmi5WgLQsxtn
6fTdn+EomE4+0V1Q38of2pxoukmZjWhIdwkpIMCW5lzoBtU9LcbqyS6j
4T+wLUnKVLT6oZUCFYMwWBPCcbpjb+0GKS49QyIJTXbDObj3HmADYSXk EJc=

Ya que todo esto se basa en zonas de confianza la zona padre, es decir la entidad en la cual
registramos el dominio debe soportar DNSSEC para que sirva en un ambiente público y real.

Herramientas
checkconf

Existen dos herramientas para verificar la configuración de BIND: named-checkconf y named-

checkzone.

La primera sirve para verificar la configuración general del servicio:

# named-checkconf

La segunda sirve para probar las configuraciones de cada una de las zonas:

# named-checkzone [Link] [Link]

En el ejemplo de arriba, [Link] es la zona y [Link] es el archivo de la zona.

Herramienta DIG

Dig es una herramienta de linea de comandos que realiza busquedas de registros DNS.

El funcionamiento se basa en realizar la consulta DNS a todos los nombres de los servidores
listados en el fichero /etc/[Link]

Uso de DIG

$ dig [servidor] [nombre] [tipo]

Por ejemplo, se realizara una consulta para el dominio [Link] .

 $ dig [Link]

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> [Link]

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48198
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;[Link]. IN A

;; ANSWER SECTION:
[Link]. 120 IN A [Link]

;; Query time: 35 msec

;; SERVER: [Link]#53([Link])
;; WHEN: Wed Jun 16 18:21:36 -03 2021
;; MSG SIZE rcvd: 55

Modo short.

$ dig [Link] +short

[Link]

Especificar un servidor de nombres para la resolución.

$ dig @[Link] [Link] +short

[Link]

Consultar todos los registros.

$ dig [Link] ANY

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> [Link] ANY

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45268
;; flags: qr rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;[Link]. IN ANY

;; ANSWER SECTION:
[Link]. 289 IN A [Link]
[Link]. 289 IN A [Link]
[Link]. 289 IN A [Link]
[Link]. 289 IN A [Link]
[Link]. 289 IN A [Link]
[Link]. 289 IN A [Link]
[Link]. 289 IN AAAA 2800:3f0:4003:c00::8b
 [Link]. 289 IN AAAA 2800:3f0:4003:c00::64
[Link]. 289 IN AAAA 2800:3f0:4003:c00::71
[Link]. 289 IN AAAA 2800:3f0:4003:c00::8a
[Link]. 21589 IN NS [Link].
[Link]. 3589 IN TXT "MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
[Link]. 3589 IN TXT "v=spf1 include:_spf.[Link] ~all"
[Link]. 3589 IN TXT "google-site-
verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
[Link]. 589 IN MX 30 [Link].
[Link]. 589 IN MX 20 [Link].
[Link]. 21589 IN CAA 0 issue "[Link]"
[Link]. 3589 IN TXT "globalsign-smime-
dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
[Link]. 49 IN SOA [Link]. [Link]. 379680302 900
900 1800 60
[Link]. 21589 IN NS [Link].
[Link]. 3589 IN TXT "apple-domain-verification=30afIBcvSuDV2PLX"
[Link]. 21589 IN NS [Link].
[Link]. 3589 IN TXT "facebook-domain-
verification=22rm551cu4k0ab0bxsw536tlds4h95"
[Link]. 3589 IN TXT "google-site-verification=TV9-
DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
[Link]. 589 IN MX 10 [Link].
[Link]. 21589 IN NS [Link].
[Link]. 3589 IN TXT "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
[Link]. 589 IN MX 50 [Link].
[Link]. 589 IN MX 40 [Link].
[Link]. 3589 IN TXT "docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"

;; Query time: 36 msec

;; SERVER: [Link]#53([Link])
;; WHEN: Wed Jun 16 18:25:52 -03 2021
;; MSG SIZE rcvd: 1086

Herramienta RNDC

rndc controla la operación de un servidor de nombres. Se comunica con el servidor de nombres

por una conexión TCP, enviando comandos autenticados con firmas digitales. Todos los
comandos que se envían por el canal se deben formar por key_id conocido por el servidor.

Uso de RNDC

Recargar los archivos de configuración y las zonas.

# rndc reload

Este comando vuelca las estadísticas del servidor de nombres en el archivo determinado por el
parámetro statistics-file , cuando no está determinado se vuelca en el archivo [Link] del
directorio de trabajo del servidor bind.

# rndc stats

Activar o desactivar el log de consultas.

 # rndc querylog on
# rndc querylog off

Detener el servicio.

# rndc stop