Curso Bases del DNS, instalación y configuración moderna

Módulo 2: DNS autoritativos.

Capítulo 1: Arquitectura de autoritativos.

En esta sección nos enfocaremos en uno de los dos grandes servicios del DNS: los
autoritativos.

Como vimos, los servidores DNS autoritativos son los que contienen un subárbol del
DNS, que son delegados desde un padre y a su vez pueden subdelegar otras ramas
a otros autoritativos. Si no delegan nada, se trata de hojas terminales del árbol.

No hay un límite a la cantidad de servidores de nombres que pueden ser autoritativos

de una zona, pero sí un mínimo definido por el RFC1035: dos. Sin embargo, la
recomendación es mantener del estilo de 3 a 5 NSs, ojalá todos por organizaciones
independientes o al menos en redes independientes, de forma que actúen como
respaldo en caso que uno se caiga. Hay algunos mecanismos abusivos que utilizan
dos NS con nombres distintos, ¡pero que tienen la misma IP! O incluso con dos IPs
distintas pero hospedados en el mismo hardware. Incluso si los dos NS están en el
mismo ASN, puede que queden fuera del aire al mismo tiempo, en caso de problemas
de red. En general cada uno sabe cuán protegido quiere sus NS, pero lo
recomendable es ojalá usar ASN distintos, que asegure organizaciones y ubicaciones
topológicas distintas.

Como vimos anteriormente, todos los NS son iguales del punto de vista de un resolver.
No hay diferencia en el orden de respuesta ni tampoco sobre cuál es primario ni
secundario. Todos deben responder igual.

Ahora, para definir la arquitectura del servicio, por supuesto que lo primero es definir
dónde se mantendrá la zona, y cuál será el primario. Este primario es donde se
cargará en primer lugar la zona desde el archivo de zona en disco, y será quien
distribuya esta zona al resto de secundarios, mediante el protocolo AXFR o IXFR del
mismo DNS.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 1

También existe otro truco bastante común, que es el tener un "primario escondido".
Esto es conveniente por seguridad, porque de esa forma todos los NS visibles son
secundarios de este primario, y el primario real se mantiene "oculto", sin necesidad
de responder consultas DNS desde Internet. Además, uno podría ser aún más robusto
teniendo varios primarios escondidos, con la directiva "multi-master" que permite que
los secundarios transfieran desde cualquiera de ellos.

El primario es quien carga la zona desde disco. Pero ¿cómo obtienen los secundarios
la copia? En el protocolo original, los secundarios debían consultar periódicamente al
primario por el serial del SOA, para así saber cuándo debían actualizarse. La
periodicidad también venía definida en el mismo SOA, en el campo "refresh". Este
define el número de segundos en que un secundario debe "refrescar" la zona. Pasado
ese tiempo, un secundario debe consultarle el SOA al primario, comparar el número
serial, y si es mayor que el que tiene, iniciar una transferencia de zona mediante el
mensaje AXFR o IXFR (AXFR es transferir la zona completa, IXFR transfiere sólo las
diferencias. Es una optimización útil para zonas muy grandes).

Sin embargo, en el DNS moderno existe otro mecanismo mejor. Cuando hay un
cambio de zona en el primario, tener que esperar el tiempo de "refresh" para que el
secundario consultara era demasiado lento. Se inventó entonces los mensajes
"notify", que el primario puede enviar a los secundarios diciéndoles "¡hey, hubo un
cambio de zona, sería bueno que hicieras una transferencia!". Un secundario al recibir

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 2

este notify autorizado desde el primario, debe iniciar la consulta serial del SOA
seguido de una transferencia, en caso que sea mayor.

Eso es básicamente lo que se debe tener claro al definir la arquitectura de DNS

autoritativos:
- ¿quién será el primario?,
- ¿será un primario público o escondido?,
- número y ubicación de secundarios,
- el primario debe configurar la carga de la zona desde el disco, definir dónde
se enviarán los notify, y autorizar las transferencias desde los secundarios;
- los secundarios deben saber el nombre de la zona, dónde está el primario,
autorizar la recepción de notify desde el primario, y transferir la zona desde esas
mismas IP.

Capítulo 2: Implementaciones de servidores DNS open source.

Primero veremos las implementaciones de código abierto más importantes en el
mundo de los autoritativos DNS, para tener un panorama y hacer una elección
adecuada.

Durante muchos años este mercado estuvo dominado por Bind de ISC, una de las
primeras implementaciones del DNS y por mucho tiempo la implementación "de
referencia", llegando a ocupar el 70% del mercado. En realidad, Bind es una suite de
programas, y el responsable del DNS es "named" (name daemon).

Bind está desarrollado en lenguaje C y se encuentra disponible para ambientes Linux,

BSD y macOS. El software se puede utilizar gratis con funcionamiento completo, y
existe suscripción pagada para tener acceso a soporte y algunas funcionalidades
avanzadas. La empresa que lo desarrolla se llama Internet Systems Consortium,
basada en Estados Unidos.

Bind puede actuar simultáneamente como autoritativo y recursivo, pero no es

recomendable mezclar las dos funciones. Es posible desactivar cualquiera de ellas, y
es preferible tenerlas separadas en distintas máquinas o servicios.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 3

Se mantiene siempre al día con las nuevas extensiones del DNS, y es uno de los
primeros lugares donde se implementa.

Ventajas del uso de Bind: es el estándar "de facto", soporta todas las
funcionalidades de DNS, tiene bastante documentación y gente que lo conoce.
PowerDNS es un software de autoritativo que ha ganado bastante mercado en el
segmento empresarial, sobre todo en Europa. La empresa es parte del conglomerado
europeo Open-Xchange, basado en los Países Bajos.

Está escrito en C++, y está disponible para ambientes Linux y Unix, como BSD.

Una de las grandes características de PowerDNS era su soporte nativo para mantener
la información de las zonas en bases de datos, lo que lo diferenciaba del esquema
habitual de archivos de texto. También permite hacer scripts para manipular las
respuestas, en lenguajes como Lua, Java, Python, etc.

Existe una versión pagada con soporte, consultoría y entrenamiento, y también tienen
hosting de DNS.

Al igual que Bind tienen un soporte completo de características básicas del DNS.

Mención aparte es que PowerDNS también desarrolla "dnsdist", un software único

que permite hacer balanceo de carga en DNS, y al mismo tiempo integrar funciones
como limitación de tasas de consulta, interceptación de preguntas, entre otros.

Ventajas de usar PowerDNS: es más cercano al ambiente empresarial, con servicios

de consultoría y diseño de soluciones. Tienen mejor soporte para bases de datos, lo
que permite integrarse a otros sistemas en uso.

NSD es un software autoritativo que es desarrollado por el laboratorio de .NL, de los

Países Bajos.

Escrito en lenguaje C, se caracteriza por ser muy liviano y rápido, con una
implementación moderna. Tiene la opción de suscripción a soporte y consultorías.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 4

Se usa en distintos TLDs, root servers y empresas. Se caracteriza por ser bastante
avanzado y liderar el desarrollo de nuevas características, lo que proviene de su
génesis dentro de un laboratorio de investigación.

Ventajas de usar NSD: especializado, pequeño, rápido y eficiente. Simple de utilizar.

La ventaja es tener un servicio simple y enfocado a lo autoritativo.

Knot es un software DNS autoritativo desarrollado por el NIC de .CZ, de la República

Checa.

También escrito en el lenguaje C, es rápido, seguro, e implementa todas las

características básicas del protocolo DNS. Dentro de los mayores TLDs que utilizan
Knot se encuentra .CZ por supuesto, y RIPE (el registro de direcciones IP de Europa).

No ofrece versión pagada, y el soporte se realiza en listas de discusión gratuitas.

Ventajas de usar Knot: especializado, pequeño y simple de utilizar. Su

implementación de DNSSEC es muy simple de configurar.

Por supuesto cualquier lista es incompleta. Me quise enfocar en los más conocidos.
Todos ellos son una apuesta segura, son conocidos y estables, y sus desarrolladores
participan habitualmente de IETF y distintos foros de operadores DNS. Lo importante
es que esta diversidad genética de software DNS le hace bien al ecosistema, y los
beneficiados somos todos en la comunidad con mayores opciones al momento de
elegir.

Ahora mencionemos algunos de los más conocidos en el ambiente de código privado.

Ahí tenemos por supuesto a Microsoft DNS, que está integrado al servicio Active
Directory de Windows, lo que lo hace muy cómodo para empresas que utilizan esa
plataforma.

Secure64 DNS es otro favorito en ambientes empresariales de mayor escala. Está

disponible como un appliance que incluye su propio hardware, o para instalar como
máquina virtual.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 5

Nominum es otra empresa que desarrolla su propio autoritativo DNS, y es utilizado en
grandes ISP principalmente, como Telefónica y Comcast. Actualmente fue adquirido
por Akamai, y cuenta entre sus filas y como fundador nada menos que a Paul
Mockapetris, el inventor del DNS.

Infoblox también apunta al mercado empresarial grande. Cricket Liu, el autor de la

biblia del DNS está entre sus filas. Este software se integra a una serie de soluciones
de seguridad y administración de redes empresariales.

En el resto de los módulos utilizaremos a Bind como ejemplo, para ser un poco más
neutral si es posible. Todas las características que se indican son soportadas por los
4 grandes del código abierto mencionado antes, y es posible revisar en su
documentación la forma particular en que se implementan.

Capítulo 3: Definición y carga de Zonas.

El formato de las zonas en Bind es un archivo de texto en "formato canónico", un
estándar de IETF que define la forma de escribir las zonas. La utilización de este
formato permite una fácil interoperabilidad, permitiendo tomar una de estas zonas y
cargarla en prácticamente cualquier otro software de DNS.

• Entonces, una zona es un archivo de texto con un formato particular.

• Los comentarios comienzan con punto y coma, y pueden estar en cualquier

parte de la línea.

• Los espacios en blanco pueden ser múltiples, o con tabs. Es solo por un tema
de legibilidad que se alinean.

• Las líneas en blanco se ignoran.

Se permiten los tokens de control "$ORIGIN <domain name>", que define el sufijo de
todos los RRs que lo siguen, en caso que sean relativos; y "$INCLUDE <file name>"
que permite insertar el contenido de un archivo dentro de otro.

El formato de los RRs es “<owner name> <TTL> <clase> <tipo> y <rdata>”.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 6
Recordemos que cualquier zona necesita al menos 1 nombre de dominio en el ápex,
con los tipos SOA y NS. En este primer ejemplo lo escribimos en el formato completo.

Acá vemos cómo se define el registro SOA, con sus campos numéricos acompañados
de comentarios, para recordar qué representan. Luego lo siguen dos registros NS con
los nombres de los servidores de nombre para la zona. Fíjense que el primero de ellos
es parte de la misma zona, y el segundo pertenece a un árbol del DNS completamente
distinto, el .com.

Un punto muy importante, y es la primera causa de errores al cargar zonas, es que

todos los nombres de hosts deben estar en formato absoluto, es decir, CON UN
PUNTO FINAL. Si recuerdan, un nombre de dominio en formato absoluto incluye al
final la raíz del DNS, que es vacía, por eso es un punto final.

Podemos revisar si la zona está sintácticamente correcta revisándola con el comando

"named-checkzone", que es parte de la suite de programas de Bind. Acá lo vemos.

La opción "-i none" le indica que no realice tests especiales de "siblings", luego viene
el nombre de la zona y finalmente el archivo de la zona.

Pero ¡tenemos un error! Lo que sucede es que pese a que tenemos lo mínimo, que
es 1 SOA y 1 NS, nos falta la dirección IP de uno de los NS, que es parte de la misma
zona. En este caso, el registro A o AAAA es obligatorio. Agreguémoslo entonces.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 7

Ahora lo volvemos a chequear, y ya tenemos un archivo de zona sin errores.

Si utilizamos la directiva "ORIGIN", podemos ahorrarnos repetir el nombre del

dominio.

Al definir con “$ORIGIN” el nombre de la zona, podemos ahorrarnos escribirla al final

de los nombres de los RRs, como se ve en ns1. Además, se puede usar el carácter
especial "arroba" (@), para reemplazarlo por el ORIGIN, como se ve en el SOA. Por
último, un RR que parte con espacios, se considera que está asociado al mismo owner
name anterior, como es el caso del NS.

Este ejemplo de zona mínima ya puede cargarse en un DNS autoritativo, y comenzar

a tener vida.

Para cargarla en un Bind, es necesario indicarlo en su configuración mediante la

directiva "zone".

¡Muy importante también acá es los puntos y coma del final del bloque! Otra fuente
común de errores.

Entre comillas después del token "zone" va el nombre de la zona. Dentro lo mínimo a
configurar, debemos declarar si es una zona primaria o secundaria (antiguamente se
le llamaba master o slave, pero ahora por correctitud política se le cambió el nombre).
Si es primary, quiere decir que será definida mediante un archivo de zona local, y
luego se declara dónde está el archivo.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 8

Es importante además revisar otras opciones de la configuración, entre ellas las IPs
donde se va a escuchar, y los puertos. Por lo general las distribuciones definen de
paquete que se escuche en direcciones locales loopback (127.0.0.1 y ::1), y en el
puerto 53, que es el default.

Como mencionamos en un capítulo anterior, no es bueno mezclar la función de

recursivo y autoritativo en el mismo servicio. Por lo tanto, como este servidor será
autoritativo, agregamos las siguientes líneas en la configuración.

Con esto, ¡ya podemos levantar Bind y probar nuestra nueva zona! Por lo general el
nombre del servicio se llama "named".

Es importante al utilizar el comando "dig" hacia un autoritativo, de poner

explícitamente la opción "+norec", que se preocupa de configurar la consulta sin el bit
"rd". Hay algunos autoritativos que al recibir una consulta recursiva pueden
rechazarla, o responder de forma distinta. Siempre al consultar un autoritativo, si
queremos simular cómo se comporta un recursivo real, se debe agregar "+norec".
Recibimos en la respuesta el status NOERROR, con 1 registro en ANSWER, y ahí
viene nuestro SOA tal como lo definimos. Además notamos que el autoritativo además
nos agregó los NS en la sección AUTHORITY y el glue en ADDITIONAL, porque es
un servidor muy amable y pensó que nos podría servir.

Ahora tenemos entonces nuestro servidor respondiendo por una zona, ¡felicitaciones!
Pero, ¿podemos considerar que nuestro servidor ya es parte del DNS global? De
ninguna manera. Para eso, necesitamos "colgarlo" de algunos de los nombres reales
en Internet. ¡Ningún resolver del mundo al ser consultado por ejemplo.cl vendrá a
buscarlo a nuestro servidor! Esto es porque ahora necesitamos decirle a nuestro
padre que somos autoritativos del dominio.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 9

Antes de ir a nuestro padre a colgar nuestra zona del árbol DNS, debemos agregar al
menos 1 secundario. Los padres son estrictos en que cualquier zona debe tener al
menos 2 NS, y nosotros solo tenemos 1. ¿Cómo lo hacemos?

Lo primero es que en nuestro primario debemos hacer dos cambios: usar una IP
pública, y declarar en la zona quiénes serán los secundarios, para que les de permiso
de transferencia de la zona.

En este caso tendremos dos secundarios de la zona. Los "notify" no es necesario

configurarlos. Por defecto, Bind los envía a todos los NS indicados en la zona.

La configuración del secundario es muy simple. No es necesario darle un archivo de

zona, porque lo obtendrá del primario. Solo debemos indicarle desde dónde obtenerla,
con la directiva "primaries".

La directiva "file" en el caso de un secundario, es el archivo donde se guardará una

copia de la zona. ¡No es para leer la zona desde ahí!

Ahora ya podemos actualizar nuestra zona con los NS reales.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 10

En este caso, definimos todos los nombres de los NS como parte de la misma zona,
por lo que es necesario declararlos como registros AAAA. También es posible usar
nombres en otros lugares completamente distintos, en caso que estén configurados
correctamente en sus propias zonas.

También aprovechamos de crear un nombre nuevo dentro de la zona, que nos servirá
para hacer consultas externas.

Una vez que los secundarios ya fueron configurados y reiniciados, podemos ya

reiniciar el primario y verificar que todo fue bien. En el log del primario debiéramos ver
que la zona se cargó correctamente, que se enviaron los notify a los secundarios, y
que los secundarios realizaron la transferencia de zona.

Y ya podemos consultar nuestra zona ejemplo.cl en cualquier secundario, obteniendo

el mismo resultado que al primario. Recuerden que todos los NS deben dar la misma
información.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 11

Por último, falta la etapa de pedir la delegación del nombre al padre. En este caso, el
padre es CL, que tiene su forma particular de subida de información. Por lo general
un nombre de dominio se compra a un "registrar", nombre que tiene un
comercializador de nombres a clientes finales. Cada registrar tiene su interfaz,
generalmente web, en donde al ingresar a un panel de control es posible modificar
los NS de un nombre. En este caso debemos informar en nuestro registrar de
ejemplo.cl que los NS de la zona son ns1.ejemplo.cl, ns2 y ns3; y además debemos
repetir las IPs de los nombres, para que sean informadas como glues en la
delegación.

Luego de esto, podemos verificar consultando a alguno de los NS del padre por la
delegación.

Primero averiguamos algún servidor de nombres del padre, consultando por el tipo
NS de CL.

Podemos utilizar cualquiera de ellos, pero es importante que la consulta por nuestro
dominio sea dirigido a alguno de los autoritativos, ¡nunca a un resolver! Esto porque
en caso de que aún no esté la delegación lista, obtendremos de respuesta un
NXDOMAIN, y el resolver lo almacenará en su caché por algún tiempo. Siempre en

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 12

caso de estar revisando una delegación, se debe dirigir al autoritativo que
corresponda, y no a un resolver.

Acá dirigimos la consulta a a.nic.cl, y ya tenemos la respuesta con nuestros NS y los

glues.

Ahora sí, que ya tenemos certeza que está bien delegado, podemos hacer la prueba
final, enviando una consulta por el registro TXT a un resolver público cualquiera, como
Quad9 en este caso.

Felicidades. Nuestra zona ya está publicada en el árbol DNS.

Reversos de IPs
Otra labor bastante común en operadores de redes es tener que declarar las "IPs
reversas" para ciertos nombres. Por ejemplo, las buenas prácticas dicen que los
servidores de nombre y los servidores de correo deben tener reversos bien definidos,
y calzar con el nombre "directo".

En nuestro caso, supongamos que queremos recibir los correos de ejemplo.cl en un

servidor de correo llamado "mail.ejemplo.cl", por IPv4. En nuestra zona ejemplo.cl hay
que agregar dos registros nuevos.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 13

El primer registro de tipo MX es el que define qué máquina recibirá los correos. El
número 1 es la prioridad, que es útil cuando se dispone más de una máquina. Luego
va la dirección IPv4 de la máquina. En este caso ponemos una privada, pero es solo
de ejemplo.

Ahora a los reversos. Para declarar los reversos debemos "dar vuelta" la dirección IP.
En IPv4 es por octeto, y se le pone de sufijo in-addr.arpa. Entonces, el registro PTR
que necesitamos para el correo, que recordemos tenía de nombre mail.ejemplo.cl y
registro A 10.14.2.25, sería 25.2.14.10.in-addr.arpa.

De igual forma, si queremos poner un reverso de uno de los NS de la zona, por

ejemplo ns1.ejemplo.cl, que tenía dirección AAAA 2001:DB8::53, debemos utilizar el
nombre 3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Recordemos que en IPv6, un par "dos puntos" seguidos, ¡en realidad son ceros!

Ahora lo importante es: ¿en qué zona van estos registros?

Los reversos son delegados desde la raíz del DNS a los RIRs de cada región, los que
a su vez los subdividen y subdelegan a las organizaciones que las administran. En el
caso de nuestra región, es LACNIC quien asigna los bloques IPs, por lo tanto son
ellos nuestro "padre" desde donde delegamos las zonas de reversos.

Si la dirección IP que están utilizando para su servidor es entregada por su proveedor

de Internet, o su empresa de hosting, es a ellos a quienes deben solicitarle el servicio
de reverso.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 14

Pero si la dirección IP a la cual quieren definirle un reverso está bajo su control, y fue
otorgada por LACNIC, tienen que entrar a su panel de control en mi.lacnic.net y buscar
la sección de reversos, para tener claro cuál es el nombre que deben delegar.
Supongamos que en nuestro caso hipotético del servidor de correos 10.14.2.25,
LACNIC nos delegó el barra 24 10.14.2.0/24.

Nuestra zona sería entonces la 2.14.10.in-addr.arpa, y dentro tendría todos los PTRs
que queramos definir para nuestras IPs. En este caso, solo tenemos la 25, que es
nuestro mail.ejemplo.cl.

Para IPv6 si recuerdan, nuestro ns1 tiene la IP 2001:DB8::53, que se transforma en

la zona 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa, y dentro tenemos la IP
3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 de prefijo, que corresponde a ns1.ejemplo.cl.

Luego de tener estas zonas cargadas y funcionando en nuestros NS, vamos a

LACNIC y declaramos estos mismos NS como autoritativos de nuestros reversos, con
lo que nos colgamos del árbol DNS reverso correspondiente.

Una opción muy útil para calcular "el número de ceros" en IPv6 es utilizar "-x" en dig,
que transforma la IP a su formato reverso. Por ejemplo, para consultar el formato del
reverso de nuestro NS, le pasamos la dirección IPv6.

Aunque la respuesta da NXDOMAIN, porque es una dirección IP inexistente,

podemos revisar la sección QUESTION, donde vemos cuál sería el reverso correcto.

Capítulo 4: DNSSEC, firma de Zonas.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 15

Ahora veremos cómo firmamos nuestra zona.

Tal como vimos anteriormente, los pasos a grandes rasgos son:

• Primero, definir nuestra política de firmado, es decir, qué algoritmo vamos a

utilizar, tamaño de llaves, tiempo de validez, tiempo de rotación de llaves,
etcétera;
• segundo, firmar la zona en el primario;
• tercero, transferir la zona a los secundarios;
• cuarto, pruebas de validación, para asegurarnos que las firmas están
criptográficamente correctas;
• quinto, enviar nuestro DS al padre, con lo que ya se arma la cadena de
validación completa, y;
• sexto, monitorear, en especial preocuparse de revisar la próxima rotación de
llaves.

Bind trae una política por default, pero utiliza 1 sola llave para el DNSKEY set, llamada
"common signing key". No recomiendo utilizar esta política, porque como vimos
anteriormente, es mejor utilizar dos llaves, una KSK y otra ZSK, lo que permite tener
la KSK por mucho tiempo, y solo ir rotando en forma más frecuente la ZSK. Eso nos
permite no tener que estar cambiando las llaves en el padre muy seguido, que puede
ser engorroso.

Para ello, definimos una política propia, y le damos el nombre "standard".

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 16

Definimos una KSK, llave que firma otras llaves, que tiene una duración de 1 año y
utiliza el algoritmo de curvas elípticas indicado. Este algoritmo es el recomendable en
estos tiempos. Tiene un soporte casi universal, y genera llaves mucho más pequeñas
que RSA, con un nivel de seguridad comparable.

La ZSK, la llave que firma el resto de la zona se rotará cada 30 días, con el mismo
algoritmo. Al rotar esta llave no es necesario contactar al padre, así que podemos
hacerlo más frecuente.

Luego, utilizamos la política anterior en nuestra zona, agregando esa línea en la

configuración anterior

Reiniciamos la configuración con el comando de control de Bind "rndc reconfig", ¡y

eso sería todo! Ya tenemos nuestra zona firmada, con 1 línea de configuración.

Podemos mirar en el log que todo salió bien. Acá vemos la creación de las llaves, con
identificadores 10376 la KSK y 23260 la ZSK.

Y luego la firma de la zona con la activación de las llaves.

Ahora podemos consultar directamente al primario, preguntándole por las llaves y

firmas.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 17

Ahí vemos las dos llaves de la zona, y acompañados de las dos firmas, la de la KSK
y la de la ZSK.

La KSK se identifica por el campo flags de valor 257, y la ZSK utiliza el 256.

En las firmas podemos ver los identificadores de las llaves al final de las líneas, la
10376 y 23260.

Con el reinicio de la zona automáticamente se debió propagar los notify y los

secundarios debieron haberse actualizado. Podemos chequear también con ellos que
todo está firmado correcto.

Ahora podríamos hacer un chequeo de validez más completo, asegurándonos que

las firmas son criptográficamente válidas. El problema es que ¡aún no estamos
delegados desde el padre! Pero hay una forma de hacer la prueba, antes de delegarlo.
Podemos utilizar una herramienta que acepte una llave pre-configurada, y realice el
chequeo. Una de las que lo permite, que funciona por web, se llama zonemaster.
Podemos entrar a zonemaster.net.

Necesitamos tener el DS de nuestra zona, que se obtiene utilizando la herramienta

"dnssec-dsfromkey" y dándole el archivo con la KSK, como se indica en el comando.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 18

Vemos que en el formato de RR se tiene el tipo DS, luego el identificador de llave,
algoritmo, tipo de resumen, y en la línea siguiente está el "digest" completo.

Ahora en zonemaster.net ponemos el nombre de dominio "ejemplo.cl", y escogemos

la opción "Opciones" para que se abra el menú completo de pre-delegación.

"Perfil" lo dejamos con "default". En "Servidores de nombre" ponemos la dirección IP

de nuestro primario (2001:DB8::53) y abajo en la sección "Firmantes de Delegación"
ponemos los campos de nuestro DS. En "Tag de Llave": 10376, en "Algoritmo": 13,
que corresponde a nuestro ECDSA de curvas elípticas, en "Tipo de resumen": 2, y
finalmente en "Resumen" copiamos el campo final completo, el que comienza con
B92E22.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 19

Presionamos arriba el botón "Check", y con eso la herramienta zonemaster va a
verificar nuestra zona, y va a utilizar el DS como si fuera obtenido desde el padre, .CL.

Una vez que está todo bien, ya podemos ir al padre y entregarle el campo DS de
arriba, según el formato que cada registrar permite. Es muy importante que esta etapa
sea hecha una vez que todos los secundarios ya tengan la zona firmada, y además
que ya expiró en todos los cachés de los recursivos alguna versión anterior de la zona,
sin firmar. Para ello es recomendable esperar al menos el doble del TTL del máximo
de nuestros registros.

Como hemos visto, la automatización de firmas y validación DNSSEC está bastante

avanzada, salvo en un pequeño punto: el envío del DS a nuestro padre. Actualmente
sigue siendo un proceso manual, fuera del DNS, que requiere copiar información y
pegarla en el panel de control de nuestro registrar, cada vez que exista un cambio en
la KSK, como un rollover.

Sin embargo, ya existe una solución en desarrollo que está de a poco siendo adoptada
por distintos TLDs. Este mecanismo permite que el hijo envíe una señal al padre
mediante la publicación de un registro especial, llamado CDS, "child DS". El padre
debe activamente escanear a sus hijos, y cada vez que vea un registro CDS, debe

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 20

copiar esa información en un DS del padre, y así actualizar el registro de delegación
segura.

Cada TLD puede tener sus propias políticas de CDS. Por ejemplo algunos requieren
que la primera vez que se active DNSSEC este DS sea puesto manualmente en el
panel de control; pero de ahí en adelante todos los rollovers serán automatizados con
el registro CDS. Otros permiten que se active DNSSEC desde cero, pero exigen que
el CDS se mantenga funcionando por una cantidad de días antes de aceptarlo.

Actualmente los softwares como Bind y Knot ya publican automáticamente el registro

CDS cada vez que hay un cambio de llaves, por lo que es solo cosa de esperar que
los TLDs activen el servicio, y será aún más automático el manejo de llaves DNSSEC.

Capítulo 5: Monitoreo utilizando DSC.

Uno de los softwares de código abierto más utilizados para monitorear DNS es DSC:
“DNS Statistics Collector”, actualmente mantenido por la organización DNS-OARC.

Se compone de dos sistemas separados. El primero es el "collector", que recopila el

tráfico DNS mediante captura de paquetes usando pcap, y por ende debe instalarse
en todos los DNS autoritativos; y el "presenter" que recibe el tráfico y crea los gráficos.
El collector es pequeño y eficiente, se configura para cada cierto tiempo mandar
información procesada al presenter, por lo que no requiere gran espacio en disco. El
presenter en cambio requiere una máquina ojalá dedicada, con suficiente espacio
para almacenar información histórica, y con capacidad de procesamiento suficiente
para la generación de los gráficos.

Pueden tener más información de requisitos, instalación y otras preguntas en el sitio

oficial de DNS-OARC en dns-oarc.net/oarc/data/dsc. Existen otros proyectos
derivados de DSC como una integración con Grafana, para integrarlo con otros
presentadores de monitoreo.

Acá veremos algunos de los gráficos que genera, con una explicación de cómo
interpretarlos. Todas estas imágenes se obtuvieron también desde el sitio de DNS-
OARC.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 21

Acá tenemos cómo se ve una distribución de tráfico por nodo. Cada color representa
uno de los distintos servidores DNS, sean estos unicast o anycast. En el eje vertical
tenemos el tráfico en consultas por segundo, en el eje horizontal la unidad de tiempo.
Estos se pueden cambiar para mostrar la última hora, día, semana y mes. Acá vemos
por ejemplo que el nodo de color rosado de arriba tiene un tráfico aproximado de dos
mil queries por segundo, lo que contrasta con el verde que tiene un poco menos de
mil. También podemos ver que alrededor de las 18:30 hubo un incremento leve en el
tráfico, que fue similar en todos los nodos. El resto se ve bastante estable.

Este gráfico es muy útil para detectar si algún nodo está llevando demasiado tráfico
comparado con el resto, lo que indica que sería bueno balancearlo con algún
mecanismo BGP, en caso de ser anycast. También se puede ver claramente con
escalas de tiempo más amplias si hay alguna sobrecarga en ciertos momentos, o si
hubo algún ataque DoS, por ejemplo.

En este segundo gráfico vemos una clasificación de las consultas por tipo. Cada color
es un tipo distinto. Acá vemos que el rojo es por lejos lo más común, que representa
el tipo A, direcciones IPv4. También vemos que el azul destaca, que representa el
tipo PTR, de reversos. En el eje izquierdo tenemos el tráfico en consultas por
segundo. Este gráfico es útil para ver su eventual cambio en el tiempo, que podría
representar alguna evolución en el comportamiento de resolvers.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 22

Un poco más útil para la operación es el siguiente gráfico, que representa los códigos
de respuesta RCODEs del servidor. El color verde es NOERROR, indicando
respuestas correctas. El rojo indica NXDOMAIN, es decir que fueron consultas por
nombres inexistentes. Acá es importante ir viendo que esto se mantenga estable. Un
aumento explosivo de NXDOMAIN podría indicar que alguna de nuestras zonas está
mal configurada.

En este gráfico casi no hay REFUSED, se ve una leve línea arriba de color azul, pero
un aumento de REFUSED podría indicar que alguien está delegando mi servidor a
una zona inexistente.

En este gráfico vemos el protocolo IP, o transporte, utilizado por las consultas.
Claramente UDP domina todo el tráfico, con un pequeño porcentaje en verde,
indicando TCP. Un aumento de TCP podría indicar que nuestras respuestas son muy
grandes, lo que obliga a los resolvers que utilizan UDP y se trunca su respuesta, a
reintentar con TCP.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 23

Otro dato interesante es el largo de las consultas, separado por el tipo. Acá vemos
una distribución normal en consultas de tipo A, de color rojo, con un promedio de
alrededor de 15 y 20, y las consultas de tipo PTR de color azul ligeramente más
largas, lo que es esperable considerando que los nombres de los reversos son más
complejos.

Por último, el tamaño del paquete de respuesta también es muy interesante. Acá
vemos en color verde el RCODE 3, que representa NXDOMAIN. Como se ve, se trata
de respuestas muy pequeñas, entre 100 y 150 bytes, que no tendrán ningún problema
en cualquier red. En rojo están los NOERROR, y esto es esperable que sean un poco
más grandes, al llevar registros de respuesta y algunos ADDITIONAL. Con DNSSEC
los NXDOMAIN crecen mucho más, porque dependiendo de la utilización de NSEC o
NSEC3, llevan 2 o 3 registros adicionales para demostrar la inexistencia de la
consulta, cada uno con sus respectivas firmas. Hay que tener cuidado en este gráfico

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 24

de no sobrepasar en lo posible los 1232 bytes, el límite actual para un paquete DNS
que no se fragmente.

Acá se indica el sitio oficial de DSC, dónde ver más imágenes de demostración, y el
repositorio github con el código fuente.

Capítulo 6: Uso de servicios externos.

En esta sección queremos enfocarnos en el uso cada vez más popular de servicios
de DNS hospedados en la nube, donde una empresa se encarga de mantener los
DNS autoritativos y nosotros generalmente mediante una interfaz de comandos, vía
una API, creamos zonas y registros.

Acá mencionamos algunos de los más comunes: Cloudflare, Azure de Microsoft,

Amazon, Rackspace, Google, etc.

Este es un ejemplo de uso vía API, utilizando el comando curl para solicitudes web.
El primer comando crea una zona nueva, y el segundo le agrega un registro A. Estos
ejemplos son del servicio de Cloudflare, pero son muy similares todos.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 25

Y acá vemos cómo se activa DNSSEC. Con solo esa llamada el proveedor se encarga
de crear llaves y firmar los registros, utilizando algoritmos y parámetros por defecto.

¿En qué debemos fijarnos al elegir uno de ellos? La gente de Netnod y la “Fundación
para la Internet en Suecia” han publicado una guía con recomendaciones, y acá
veremos un resumen de todas ellas.

Lo primero es si dan servicio Primario y/o Secundario. Es importante saber cómo se

manejan los datos, si es una API vía comandos, o es por un panel de control web. Si
permiten el servicio de secundario, es importante saber si pueden ustedes mismos
manejar su primario, y enviar transferencias vía AXFR.

Segundo, el transporte que utilizan. Si tienen conectividad IPv6, anycast, su

diversidad de peering, latencia en consultas, y si tienen protección ante ataques DoS.

Luego es muy importante la diversidad, para evitar puntos únicos de falla. Diversidad
en topología, geográfica o de software.

En DNSSEC es importante saber qué tipos de algoritmos soportan, tamaños de llaves

y tiempos de firmado, y si tienen firmado online u offline.

Por último, temas de contratación. Niveles de soporte, temas de niveles de servicio

(SLA) como uptime, acceso a datos de queries, tiempos de propagación de cambios
de zona, y restauración de fallas.
Ahora bien, por mucho que estudiemos y escojamos el mejor de todos los servicios,
todos se pueden caer. Por eso, si queremos mejorar aún más nuestra robustez, lo
recomendable es tener al menos dos servicios contratados en forma independiente.
Si permiten el servicio de secundario, uno podría manejar su propio primario y

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 26

transferir desde ahí a los dos servicios. Pero si utilizan solo primario vía API, hay
herramientas que permiten simplificar el manejo manteniendo solo un sistema
centralizado de información, que se despliega en múltiples servicios. Un ejemplo de
esto es "Denominator", desarrollado por Netflix.

En este caso también es posible la activación de DNSSEC, teniendo cuidado de que

ambos usen el mismo algoritmo, y enviando al padre los dos DS. Eso permite que se
valide en las dos nubes con sus propias llaves.

Curso Bases del DNS, instalación y configuración moderna / Módulo 2 27