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

Módulo 1: Introducción al DNS

Capítulo 1: ¿Qué es el DNS?

La definición más común que encontraremos es que el DNS es la "libreta de
direcciones", o "guía telefónica" de Internet. Ustedes quizás son muy jóvenes, pero
yo alcancé en mi niñez y juventud a usar guías telefónicas. La única manera de
encontrar el número de teléfono de alguien, o de alguna empresa.

En un comienzo el DNS permitía lo mismo: conectar a dos usuarios mediante la

llamada de uno de ellos, al "nombre de servicio" del otro.

Desde los inicios de Internet se vió la necesidad de mantener un catálogo de nombres

de máquinas. En un comienzo las máquinas se identificaron con su "dirección IP",
pero rápidamente surgió la necesidad de asignarles un mapeo a nombres que fueran
humanamente sencillos. Tanto por mejorar la "recordabilidad" o "memorización" de
ellos, como para dar una capa extra de "indirección", que permitiera por ejemplo tener
distintos servicios con distintos nombres, pero asociados al mismo servidor final, con
la misma dirección IP.

Claramente la analogía con una guía telefónica se queda corta muy pronto, pero es
un punto de partida.

Hay teorías que dicen que los 2 más grandes problemas de la Ciencia de la
Computación son invalidar un caché, nombrar a las cosas, y los errores de 1 bit. Es
una broma, porque esas son 3 cosas y no dos. A eso se refiere los errores de 1 bit.
Pero el DNS se ocupa de otro de los grandes problemas: nombrar las cosas.

Otra teoría más seria y académica dice que un sistema de nombres ideal debería
tener 3 características fundamentales: entendible por humanos, descentralizado y
seguro. Pero que lamentablemente no es posible tener las 3. Hay que escoger dos.

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

Durante la historia se han propuesto otros sistemas de nombres (algunos basados en
bitcoins, por supuesto) que se ocupan de otras 2 características distintas a las que se
ocupa el DNS. Visto así no es que sean mejores ni peores, solo se ocupan de otros
vértices del triángulo.

En el caso de nuestro DNS, los vértices son "entendible por humanos" y "seguro",
utilizando DNSSEC. Pero no es descentralizado en el sentido original del paper, sino
jerárquico, una característica que aunque no cumpla con lo indicado en el paper, ha
sido vital en la práctica para mantener un orden y cumplir con requisitos legales,
comerciales y de uso.

El DNS es un servicio crítico y fundamental en Internet, pero muy silencioso. Es por

eso que pasa desapercibido, y es lo que le da su "mala fama". Solo nos damos cuenta
del DNS cuando hay problemas. ¡Cuando funciona, lo olvidamos! La broma común es
"la culpa siempre es del DNS", que viene del hecho que suele ser una tecnología que
pasamos por alto al analizar problemas.

Acá vemos algunos de los memes y bromas que se le hacen al DNS por esto mismo.

El muro rayado fue parte de las protestas y desórdenes de la "primavera árabe". Una
de las técnicas que usaron los gobiernos para censurar la red fue modificar el DNS
de los grandes proveedores de Internet. Es por eso que aparecieron rayados con la
dirección IP de uno de los proveedores de DNS globales, que permitía saltarse esas
restricciones. Esto fue una de las primeras y quizás únicas veces en que el DNS fue
así de público, pero demuestra lo fundamental que es para una Internet que funcione.

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

Entonces volvemos al principio, ¿qué es el DNS?

En realidad podemos referirnos a distintas cosas cuando hablamos de DNS. Primero,

y es la definición de más "alto nivel", se puede decir que es un sistema de
nombramiento o denominación de objetos en Internet, que es común y global.

Pero también cuando hablamos de DNS nos podemos referir a la base de datos
distribuida que representa los nombres y ciertas propiedades de los objetos en
Internet.

Tercero, también cuando hablamos de DNS estamos hablando de la arquitectura

global que implementa esta base de datos, compuesta de servidores, clientes,
administración, etc. Esta arquitectura es distribuida, resiliente (es decir tiene robustez,
tolerancia a fallos y permite recuperarse frente a problemas), y es "débilmente
coherente", en el sentido que es coherente (todos ven la misma información) casi
siempre, salvo por pequeños momentos en los que hay cambios y este cambio se
"propaga" por el sistema.

Por último, y es la definición más técnica y precisa, el DNS según la IETF es un

protocolo simple de comunicación de mensajes que implementa esta arquitectura; y
está definido en dos documentos de estandarización: RFC1034 y RFC1035.

En un comienzo de la Internet, debido a la pequeña cantidad de máquinas y

participantes, los nombres se mantuvieron en un archivo de texto simple, llamado la
"tabla de máquinas de internet" ("Internet Host Table"), conocida coloquialmente
como "hosts.txt". Acá vemos un trozo del año 1983. Todos los que se conectaban a
Internet debían descargar este archivo desde lugares conocidos, usando el sistema
de intercambio FTP.

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

Una solución muy simple, pero claramente no escalable. Pronto, ya acercándose a
los cientos de computadores, se vió la necesidad de inventar un nuevo mecanismo,
que fuera escalable y "jerárquico", es decir, que permitiera delegar la administración
de los nombres a instituciones distintas.

Es así como Paul Mockapetris en conjunto con Jon Postel inventan el DNS actual, el
año 1983. Podríamos decir que el DNS fue la primera base de datos distribuida que
existió, y su éxito ha sido tal que 40 años después lo seguimos usando, y se podría
decir que prácticamente tal como fue inventado. ¡Eso es escalar a niveles
impensados! Se estima que hoy existen más de mil millones de máquinas en el
mundo, repartidas en 365 millones de nombres de dominio bajo el primer nivel.

El trabajo de Paul Mockapetris se llevó a cabo en varios documentos de estándar

abierto dentro de IETF, que ya están obsoletos, pero que se fueron actualizando hasta
llegar a los RFCs 1034 y 1035 del año 1987, que aún están activos y son la base de
cualquier participante en DNS. De ahí se derivaron no solo los DNS autoritativos (Bind
fue una de las primeras implementaciones de un DNS, y la más exitosa), DNS
recursivos y clientes, sino una industria completa de nombres de dominio; una

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

organización mundial llamada ICANN que es un modelo de gobernanza en Internet,
y es considerado lo más cercano a un "gobierno central" de Internet; y a una industria
de empresas registradoras, comercializadoras, de registros de marcas, etc, que
mueve un estimado de 8 mil millones de dólares anuales.

Pero en esos primeros tiempos la administración central estaba en manos de 1

persona: Jon Postel. El mantenía la base de datos de dominios de primer nivel, los
asignaba, y definió las primeras reglas para operar el DNS. Esta labor la mantuvo
hasta su temprana muerte, en 1998.

En esta sección nos enfocaremos en los grandes hitos del DNS.

Podríamos decir que luego de su invención, el primer cambio importante fue la del
estándar EDNS de 1998: el “Extended DNS”, que permitió ampliar el tamaño de un
paquete DNS de los 512 bytes originales, a una cantidad teórica máxima de 64KB
(pero que en la práctica se limita a un poco más de 1KB, que es suficiente para la
cantidad de información actual). Lo más importante es que además de aumentar el
tamaño, permitió definir nuevas formas de extender los códigos de respuesta del
DNS, permitiendo el surgimiento de nuevas tecnologías como DNSSEC.

El año 2003 vimos el lanzamiento de IDN, los nombres de dominio

internacionalizados, que permiten ahora disponer de muchas más letras además del
ASCII norteamericano original.

El siguiente año 2004 vió el nacimiento de DNSSEC, las extensiones de seguridad

del DNS, que le agregaron mediante criptografía la posibilidad de dar autenticación,
integridad y no-repudiación. Sin embargo, aunque el protocolo técnico existió desde
ese momento, no fue hasta el año 2010 que se habilitó a nivel mundial. Antes de eso
existieron algunos TLDs pioneros que lo implantaron en sus dominios (como el .BR
de Brasil en nuestra región), pero por la naturaleza jerárquica del DNS y DNSSEC, la
firma de la raíz marcó el momento de su lanzamiento mundial.

Luego el 2013 vimos el lanzamiento de los "nuevos TLDs genéricos" (ngTLDs), que
significó pasar de la cantidad estable histórica de alrededor de 300 TLDs a los más
de 1.500 actuales.

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

Luego el año 2018 vimos otro gran hito del DNS, la primera vez que se rotó la llave
DNSSEC de la raíz, que se había mantenido desde el 2010. Fue una gran operación
a escala mundial que significó entre otras cosas, que cada resolver del mundo
obtuviera la nueva llave y la configurara.

Finalmente, el año 2019 se realizó la primera campaña llamada "DNS flag day",
coordinada por los grandes operadores y fabricantes de software DNS, que busca
realizar una "limpieza" ordenada de los dominios y servidores anticuados existentes
en la red. Estos "DNS flag days" se seguirán repitiendo anualmente, con el objetivo
siempre de ir mejorando la estabilidad del DNS.

Como se ha indicado, el protocolo DNS es un estándar abierto, originado y mantenido

por la organización IETF (que también maneja muchos protocolos de Internet básicos,
como el ruteo BGP, correo electrónico, y la capa de comunicación de la web (HTTP)),
donde participan los principales desarrolladores de servidores DNS, clientes DNS,
académicos, investigadores, y los grandes operadores de autoritativos como los TLD.

Lamentablemente todos estos trabajos de extensión y mejoras del DNS tienen su

costo: la complejidad en la actualidad de implementar un servicio DNS desde cero.
Como se ha indicado, todo el protocolo y sus extensiones se trabajan en IETF, de
forma abierta. Pero actualmente podría ser un poco complicado navegar los distintos
estándares y extensiones.

Acá podemos ver un diagrama de dependencias de RFCs (los documentos que

genera IETF). Cada rectángulo es 1 documento que aborda alguna parte del DNS.
Las líneas conectan las dependencias entre uno y otro.

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

Acá mejor hacemos un "zoom" y nos enfocamos en los "básicos", aquellos que es
imprescindible implementar. Los primeros tres de color marrón de la izquierda son los
fundacionales de Paul Mockapetris del año 1983, que fueron actualizados en 1987,
acá en color verde. De ahí depende todo el resto de extensiones, con una gran
variedad de nuevas técnicas y definiciones.

Pero no se asusten. No es necesario que lleguen a este nivel de detalle, salvo que
quieran implementar un servidor DNS desde cero. En este curso queremos darles una
visión completa para operar un servicio DNS moderno, y les dejamos invitados a leer
todos los detalles a quienes le interese, consultando estos RFCs que son de acceso
público desde el sitio ietf.org.

Hace un par de años hubo algún movimiento dentro de IETF que pedía simplificar un
poco las cosas, o más bien un llamado a tener cuidado con la sobre-extensión. El
DNS es víctima de su propio éxito, y no son pocas las ideas de implementar web
sobre DNS, VPN sobre DNS, control de malware sobre DNS, etcétera. Se hablaba
del "DNS Camel", que es el gran riesgo de "romper la espalda" de un protocolo
muchas veces abusado. En ese momento se calculó que son 217 RFCs los
necesarios para tener un DNS moderno, totalizando 3.650 páginas de estándares que
sería necesario leer.

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

Por el momento podemos descansar en los expertos. En el mundo DNS del código
abierto, las implementaciones más importantes son Bind, que fue una de las originales
y por muchos años casi la única, mantenida por la organización norteamericana ISC;
NSD y Unbound que corresponden a la parte autoritativa y recursiva (que está
separada a diferencia de Bind), mantenida por el laboratorio de .NL, el ccTLD de
Países Bajos; Knot DNS que tiene su contraparte recursiva con Knot Resolver, del
NIC de república checa .CZ; y PowerDNS que es mantenido por una organización
europea que se caracteriza especialmente por su soporte a base de datos.

Finalmente, para terminar esta sección de introducción al DNS, debemos mencionar

qué organismos son importantes para entender el ecosistema de los nombres de
dominio.

Primero lo que ya habíamos visto. Toda la definición del protocolo, extensiones y

correcciones se realizan en la IETF, el organismo que originó los estándares en
Internet. Todos los estándares son públicos y pueden descargarse desde su sitio.
IETF divide su trabajo en distintos grupos. DNSOP es la "madre" del DNS, donde se
ven temas generales. Cuando es necesario hacer una extensión muy específica,
generalmente se organiza otro grupo de trabajo. Así tenemos a DPRIVE que ve temas
de privacidad en DNS, y ADD que ve temas de cómo las aplicaciones pueden utilizar
el DNS.

Por otro lado existe una asociación de organizaciones y empresas que trabajan en la
arquitectura y operación del DNS, llamada DNS-OARC. Esta asociación funciona con
membresías pagadas, lo que da derecho a asistir a conferencias, participar de
discusiones, definir el desarrollo de software relacionado al DNS, y diversos estudios.
Acá tenemos a muchos administradores de TLDs pero también gente del lado de los
resolvers, como Cloudflare, Google, PCH; agentes registradores como GoDaddy,
Neustar; e incluso empresas que consideran necesario aportar y reunirse en torno al
DNS como Facebook, Oracle, Cisco, Microsoft, Amazon, etc.

La administración de los nombres de dominio se agrupa en torno a ICANN, que

maneja el contenido de la raíz del DNS, y define por ejemplo los nuevos TLDs que se
creen. También define las reglas de operación de los gTLDs, como .com, .net, .info,

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

etc; y otra labor importante es definir cómo se manejan las controversias entre
nombres de dominio, llamado UDRP.

Y aunque el contenido de la raíz es definido por ICANN, los servidores raíz son
administrados por 12 organismos independientes, que totalizan 13 servidores raíz (1
organismo tiene dos). La mayor parte son de Estados Unidos, y vemos diversas
organizaciones del gobierno, universidades, etc. En Europa tenemos a RIPE (el RIR
de esa región) y a Netnod de Países Bajos. Por último, el organismo académico WIDE
maneja también un servidor raíz en Japón.

No podemos dejar de mencionar también los ccTLDs, los TLDs de los países, que
son independientes y autónomos. Acá hay bastante diversidad en los organismos,
generalmente los mantienen los propios gobiernos, o instituciones comunitarias sin
fines de lucro, o también universidades.

Y finalmente también los RIRs son importantes como organizaciones, ya que

mantienen el árbol reverso del DNS que comentaremos más adelante.

Capítulo 2: Estructura del DNS y Nomenclatura

En esta sección, separada en dos módulos, hablaremos de cómo se estructura el
DNS. Se verá el árbol de delegación, la diferencia entre recursivo y autoritativo, y
algunas diferencias en la administración del espacio.

En su definición original, el DNS se presentó como una estructura de "árbol invertido".

Debo confesar que nunca entendí mucho a lo que se refería, hasta ver esta imagen
de acá.

Es un árbol con la raíz arriba.

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

Una característica de esta estructura de datos en Ciencia de la Computación es que
no existen "ciclos" o "bucles"; ya que cada nodo puede tener muchos hijos, pero solo
1 padre, con excepción de la raíz que no tiene padre. También ocurre que cada nodo
puede ser tratado como el nodo raíz de su propio sub-árbol, lo que da interesantes
características de jerarquía. Esto, sumado a la falta de ciclos, permite usar la
"recursividad" en cualquier subárbol del DNS.

El árbol completo DNS es mantenido por distintos servidores DNS autoritativos, cada
uno siendo responsable de una o más zonas. Estos servidores autoritativos son los
responsables de uno o varios nodos del árbol, contienen los "registros de recurso"
(resource records (RRs)) de cada uno de ellos, y delegan los subdominios a otros
servidores autoritativos.

Por temas de redundancia, siempre existe más de 1 servidor autoritativo por cada
zona. El mínimo es dos, pero actualmente es común tener cuatro, en promedio. Todos
los autoritativos que se encuentran en los NS de una zona deben responder en todo
momento, y un resolver puede utilizar cualquiera de ellos indistintamente. Sin
embargo, es bastante común que desde el punto de vista de la administración de la
zona, uno de ellos sea el "primario" de la zona, y el resto sea "secundario". El primario
es donde se origina la información de la zona, y los secundarios la transfieren desde
este primario, utilizando un protocolo dentro del mismo DNS. Sin embargo, esta

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

división es solamente administrativa, de un acuerdo entre los NS, y desde el punto de
vista de un recursivo, todos ellos son iguales y puede utilizar cualquiera que desee.

Por otro lado, los servidores encargados de recorrer el árbol DNS para llegar a un
nodo en particular, se les llama recursivos, porque recorren recursivamente el árbol
DNS, o resolutores (resolvers). Se puede hacer un paralelo diciendo que los DNS
autoritativos serían algo así como los servidores web, y los recursivos los "spiders"
que recorren el árbol buscando información.

Esta diferencia entre las dos funciones de autoritativo y recursivo es crucial, y es la

primera fuente de mucha confusión en el mundo DNS. Es un concepto vital que deben
tener claro después de este curso.

Siguiendo en este mismo tema, lo que la "gente de la calle" entiende por "DNS" es
generalmente "el servidor DNS recursivo que utilizo para navegar". La gente de la
calle no se topa con DNS autoritativos generalmente, salvo cuando quiere registrar
un nombre de dominio propio, en cuyo caso necesita tener DNS autoritativos para su
nombre.

Un servicio recursivo es generalmente entregado por un Proveedor de Internet (o ISP)

para sus clientes, una empresa para sus empleados, una universidad para sus
alumnos, etc. Es un servicio esencial para usar Internet, y muy importante y básico.
También existen empresas que dan servicio recursivo gratuito o pagado, fuera de las
redes locales de cada usuario. Las veremos más adelante en otra sección.

Recuerden siempre que los DNS autoritativos son quienes mantienen la estructura de
árbol, y los DNS recursivos son quienes recorren este árbol para encontrar los
registros de recurso de un nombre.

Otra cosa importante en esta estructura de árbol es que acá no vemos las divisiones
administrativas del DNS. Una institución puede manejar un nodo del árbol, y es
responsable de lo que pase en su propio subárbol, pero no es evidente mirando el
árbol ni tampoco recorriéndolo con un recursivo, de dónde está el "corte" o "cambio"
de administración. Por ejemplo, en el caso de la raíz, la responsable de su contenido
es ICANN, una organización internacional sin fines de lucro. El primer nivel, llamado

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

"TLD" por "top-level domain", es manejado por distintas organizaciones y se separa
básicamente en "TLDs genéricos" (gTLDs) y "TLDs de países" (ccTLDs, por "country
code TLDs"). Las reglas básicas de los gTLDs se manejan centralizadamente por
ICANN, pero debajo de cada uno de ellos la organización tiene cierta autonomía en
definir ciertas políticas de uso. Por otro lado, los ccTLDs tienen autonomía absoluta,
dentro del respeto del protocolo DNS, y no necesariamente siguen las reglas de
ICANN.

Han existido intentos de reconocer estas divisiones administrativas del DNS. La más
conocida se llama "Public Suffix List", administrada por un grupo de voluntarios y
mantenida por Mozilla, que publica las divisiones "internas" de cada TLD. Por ejemplo,
ahí vemos que com.br es un sub-registro dentro de br, pero com.cl no lo es.

Las divisiones administrativas son muy útiles para que los navegadores limiten
adecuadamente las cookies, certificados digitales, etc.; y no permitan compartir
elementos entre dominios que no están relacionados.

En el DNS, cada nodo es una etiqueta (label). Un "nombre de dominio" es la dirección

única de cada nodo, que se forma concatenando la etiqueta del nodo, con la etiqueta
de sus padres hasta llegar a la raíz, separadas con un punto. La raíz es una etiqueta
"vacía", por eso en la notación "completa", un nombre de dominio termina con un
punto final, y es la forma en que se escriben correctamente en las zonas. En el caso
del ejemplo, tenemos que el último nodo de abajo tiene el nombre de dominio
campus.lacnic.net.

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

Una etiqueta puede tener un máximo de 63 "octetos" (bytes), que en el protocolo
pueden ser cualquier binario, sean caracteres ASCII o no. Sin embargo, hay un
formato reducido llamado "hostname", que es el obligatorio en el "DNS Global",
restringiéndose los binarios a ambientes privados de "DNS Local". En el formato
hostname hay más restricciones para las etiquetas. Solo se permiten las letras ASCII
A a la Z, dígitos 0 a 9, y el guión del medio (-). No se distingue entre mayúsculas y
minúsculas. No se permiten guiones en el primer ni último lugar, ni tampoco en la
tercera y cuarta posición. El nombre de dominio en total no puede exceder los 253
caracteres de largo.

Este formato es el que debe respetar cualquier nombre que quiera ser interoperable
en el DNS Global, y es el que exigen los TLDs para la inscripción de dominios.

Cada una de las etiquetas tiene asociada cero o más Registros de Recurso (RRs), y
cada RR tiene un tipo propio, además de un contenido que es dependiente de cada
tipo.

Acá vemos que la etiqueta "lacnic" tiene los RRs NS y MX. El NS es obligatorio para
una etiqueta que es el ápex de una zona, y el MX es común verlas cuando se quiere
que el nombre de dominio sea receptor de correos electrónicos. La etiqueta "campus"
tiene los RRs de tipo AAAA (también llamada quad-A) y A, que representan el uso
clásico de direcciones IPv6 e IPv4, respectivamente.

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

Una zona es un subárbol que puede contener más de 1 nivel de dominios, o varios
de ellos. Esto representa una unidad "administrativa". Cuando una administración
quiere delegar una parte del árbol a otra administración, crea una delegación, y se
separa en otra zona.

Acá vemos que .net es una zona que tiene solo 1 nodo, pero lacnic.net tiene dos
niveles. La delegación entre .net y lacnic.net divide las zonas.

En la nomenclatura de una zona que mencionamos recién, un término importante es

el "ápex". Se le llama así al nombre del dominio padre de una zona "en crudo", para
diferenciarlo de los sub-nombres bajo el dominio.

Por ejemplo, acá tenemos la zona "lacnic.net", que tiene los nombres www.lacnic.net
y campus.lacnic.net. El "ápex" de la zona es "lacnic.net", a secas. En el ápex es donde

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

viven los registros SOA y NS. También pueden existir otros registros como AAAA, A,
MX, etc, pero se usa ese término para referirse a la zona "base" del dominio.

Tal como hemos mencionado, el registro NS, que es el que define los servidores de
nombre que son autoritativos de una zona, se define en el ápex de dicha zona.

Sin embargo, es necesario también que el padre conozca estos NS, para poder hacer
la delegación y que los resolvers encuentren los NS cuando están recorriendo el árbol
DNS desde arriba hacia abajo.

Es por esto, que se da el extraño caso, único en el DNS, que el registro NS se

encuentra en dos lugares del árbol DNS. Está en el padre, y en el ápex de la zona.
Este último, el ápex de la zona, es el realmente autoritativo de esos datos, y es por
esto por ejemplo donde se encuentran las firmas DNSSEC del RR. Los datos del
padre son solo un "indicio", pero es el hijo quien debe definir los NS definitivos. ¡Esto
causa muchos problemas cuando hay inconsistencias entre estos datos!

Finalmente, para completar una visión de la nomenclatura básica, hablaremos de los

distintos actores de la arquitectura del DNS.

Partiendo por la izquierda, al nivel del usuario, tenemos las Aplicaciones que son las
que necesitan hacer uso del DNS para funcionar. Estas aplicaciones se ejecutan
dentro del dispositivo que utiliza el usuario.

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

Las aplicaciones acuden al sistema operativo para resolver un nombre. Los sistemas
operativos dan un servicio DNS llamado "Stub", cuyo rol es centralizar las consultas
de todas las aplicaciones, definir políticas internas, y hacer un pequeño "caché" para
almacenar las consultas más frecuentes. Sin embargo, este "stub" no hace resolución
por sí misma, por lo que necesita de otro recursivo para funcionar.
En este ejemplo, el usuario está en su hogar y posee un dispositivo de acceso a
Internet, el "módem" o "router" que le entrega su proveedor, que se presenta como
"resolver DNS" a los dispositivos de su red, pero en realidad actúa como "forwarder"
que solo redirige las consultas a otro recursivo.

Acá ya llegamos a un DNS recursivo real, que es parte de la infraestructura del ISP y
es compartido entre muchos usuarios. Este resolver tiene también un caché de
respuestas, de tal forma de responder rápidamente ante consultas comunes y
repetitivas, pero en caso de no tener la respuesta, su labor es recorrer recursivamente
el árbol DNS buscando la respuesta final, siguiendo las delegaciones de los DNS
Autoritativos del árbol DNS.

Esta arquitectura es sólo una de las muchas formas de organizar el servicio DNS,
pero es la más comúnmente utilizada.

Capítulo 3: Mensajes y estructura del paquete DNS.

En este módulo veremos el formato de un paquete DNS. Esto es muy útil para hacer
depuración de problemas, y entender el tipo de información que se espera de una
pregunta y respuesta.

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

El paquete DNS es una estructura que puede viajar en UDP, como era común y casi
exclusivamente en los primeros tiempos, o dentro de un stream TCP, TCP sobre TLS,
HTTPS, QUIC, etcétera. Independiente del tipo de transporte, la estructura es la
misma.

Lo primero que vemos es un identificador de paquete, llamado ID. Debe ser un

número al azar, de 16 bits, que es creado por el cliente de la transacción, o sea quien
hace la pregunta, y debe ser copiado por el servidor en la respuesta. De esa forma,
entrega un mecanismo de seguridad que la respuesta corresponde a la pregunta
correspondiente, y además permite calzar distintas respuestas que un cliente puede
tener en espera.

Luego tenemos distintos "flags". El primero, QR, se enciende cuando se trata de una
respuesta, y se pone en 0 en las preguntas. Esto permite distinguir entre una y otra.

El Opcode era originalmente para distinguir el "tipo de consulta", pero en la práctica

este campo está en desuso, y siempre es cero.

El siguiente "AA" es el "respuesta autoritativa", que se enciende solo en respuestas

donde el servidor es autoritativo para la pregunta.

El bit TC siguiente es el de "truncado", y se enciende en las respuestas donde debido

a un tamaño de datos mayor al disponible en el paquete, es necesario que el cliente
repita su pregunta vía TCP.

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

RD y RA son los bits de "deseo recursión" y "recursión disponible", el primero de ellos
es encendido por los clientes que desean que el servidor le haga recursión en su
pregunta, o bien apagada si solo desea que responda con la información que dispone
localmente

RA lo utiliza el servidor para indicar si él puede hacer recursión o no. Esto es útil si
uno envía una pregunta con el bit RD anterior encendido, indicando que solicita
recursión, pero el servidor no quiere o no puede hacerlo (puede que sea autoritativo
solamente, o bien que sea recursivo para otros clientes y no para mí) y entonces
responderá con este bit RA en cero.

Luego tenemos el campo Z que está reservado e inutilizado y debe ser cero.

Finalmente, RCODE es un campo de 4 bits donde viene el código de respuesta. Los

más comunes son NOERROR cuando todo está bien, NXDOMAIN si el nombre no
existe, REFUSED si el servidor no está configurado para este nombre, etcétera.

Siguiendo con los flags de encabezado ya vienen los RRs de la respuesta. Primero
vienen contadores de cuántos registros hay para la pregunta (QUESTION). Aunque
teóricamente uno podría poner más de 1 pregunta en un paquete, esto no está
especificado y no funciona.

En la sección de respuesta (ANSWER) se ponen los RRs de respuesta a la consulta.

Acá pueden ir los tipos preguntados, pero también las cadenas de CNAME, las firmas
DNSSEC, etc.

En la sección de autoridad (AUTHORITY) vienen las delegaciones a otras zonas

(registros NS).

Y finalmente en la sección adicional (ADDITIONAL) viene cualquier registro que

pueda ayudar a la resolución, por ejemplo los registros "glue" que indican las
direcciones IP de los servidores de nombre bajo el mismo dominio. Un resolver debe
evaluar cuidadosamente la información que viene en el adicional, y decidir si confía
en ella o prefiere realizar otra recursión completa para obtenerla.

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

Finalmente, ya vienen los datos de cada RR. El formato es el nombre de dominio
separado por etiquetas, con el largo de cada una. Luego el tipo del nombre y la clase.

En este caso vemos una pregunta, por el bit QR en cero, y 1 solo registro en la sección
query, compuesto de las etiquetas www, ietf, org y la raíz, el tipo AAAA (código 28), y
clase internet (IN), código 1. Esta pregunta está pidiendo los registros IPv6 para
www.ietf.org.

Ahora veremos cómo se realiza una pregunta y se analiza una respuesta usando una
de las herramientas más poderosas que podemos utilizar para analizar el DNS: el
comando "dig", parte del software "Bind" de la empresa ISC.

Primero veamos cómo se arma una pregunta. El identificador de una pregunta es una
tri-tupla formada por el nombre de dominio, o "qname", el tipo del RR, o "qtype", y la
"clase", qclass. La clase es una forma de tener distintos "árboles en paralelo", pero
nunca se ha desarrollado. En la práctica, la única clase que se utiliza es la "clase
Internet", o IN. Entonces, con qname, qtype y qclass tenemos identificada una
pregunta.

Acá vemos cómo realizamos la misma pregunta indicada en la estructura del paquete
DNS. El qname es "www.ietf.org", el qtype "AAAA" (una dirección IPv6), y la clase se
puede indicar, aunque es opcional, y se asume IN. Finalmente, podemos indicar

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

mediante "+rec" que queremos encender el bit de recursividad deseada, y con arroba
(@) indicar a qué servidor DNS queremos dirigir esta consulta.

Entonces, acá estamos enviando un paquete DNS a 9.9.9.9, preguntando por la

dirección IPv6 de www.ietf.org, pidiendo recursión.

La respuesta a su vez también incluirá la sección de la pregunta, copiando el ID, y

preocupándose de setear el bit RA si está dispuesto a dar recursión o no.

Las respuestas van en el campo ANSWER. Acá es importante indicar que puede
haber más de un RR por cada respuesta, por lo que se habla de "RR set", para indicar
que pueden ser múltiples. Por ejemplo, www.ietf.org puede tener 2 direcciones IPv6,
y entonces el contador de ANSWER sería 2, y venir en la sección ANSWER, 2 RRs
de tipo IPv6.

Las otras secciones se utilizan para otro tipo de respuestas. En AUTHORITY van las
delegaciones (los registros NS), junto a otros.

En el ADDITIONAL pueden ir registros extra que el servidor quiso agregar, para

ayudar en la respuesta. Por ejemplo, en el mismo caso de responder con registros
NS, el servidor puede o no incluir las direcciones IP de estos NS en el caso que las
conozca, porque es obvio que un resolver al obtener los NS lo primero que querrá
hacer es averiguar sus direcciones IP. El servidor ayuda entregando en una misma
respuesta con más información útil.

Y acá tenemos la respuesta al comando dig anterior. Iremos viendo los datos
importantes uno por uno.

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

Lo primero que deberíamos mirar es el RCODE, el código de respuesta. En este caso
es NOERROR, por lo que podemos seguir analizando el resto de información.

Otros códigos de error comunes son SERVFAIL, que entregan los servidores que no
pueden responder por cualquier problema interno; NXDOMAIN que indica que el
nombre consultado no existe; REFUSED que responden los servidores que no son
autoritativos para esa pregunta.

Luego miramos cuántas respuestas vienen. Si vienen cero hay que fijarse en el
AUTHORITY, porque si es una consulta de tipo NS es esperable que vengan ahí.

Otro caso importante de destacar es cuando hay una pregunta por un tipo distinto a
NS, también se pueden tener respuestas con RCODE "NOERROR" y cero ANSWER.
Esto indica que sí existe el nombre consultado, pero es el tipo consultado que no
existe. Por ejemplo, si pregunto por www.lacnic.net pero tipo MX, se obtendrá
NOERROR y ANSWER igual a 0.

Acá vemos los flags. Uno de los importantes cuando uno consulta a un recursivo es
que debe venir el "ra", indicando que la respuesta fue resuelta exitosamente.

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

El bit "ad" también es importante porque indica que la respuesta fue validada con
DNSSEC, indicando primero que el recursivo tiene la capacidad de validación
DNSSEC, que obtuvo registros DNSSEC desde los autoritativos, y que los pudo
validar criptográficamente, por lo que esta respuesta está "certificada" que es
correcta.

Luego ya tenemos los registros en sí mismos. Acá nos fijamos que el nombre
www.ietf.org tiene primero un TTL de 131 segundos, que indica el tiempo de caché
que le resta a ese registro. Esto se indica porque el cliente podría querer también a
su vez hacer caché de esta respuesta, y tiene derecho a hacerlo por 131 segundos.
Pasado ese tiempo, debe volver a preguntar al recursivo, por si hubiera algún cambio.

El tipo consultado fue AAAA, el que viene en este otro RR. Acá vemos que
www.ietf.org no tiene registro AAAA pero sí tiene un registro CNAME, que representa
un "alias", indicando que se debe consultar otro nombre canónico,
www.ietf.org.cdn.cloudflare.net. Esta es una técnica muy utilizada por sitios web que
utilizan el servicio de CDN, redes de distribución de contenido. Nuestro recursivo
9.9.9.9 es tan amable que, al solicitarle recursión, no se contenta con solo responder
con el CNAME, sino que se preocupa de seguir ese CNAME y llegar finalmente al
registro AAAA solicitado.

Otro dato importante para efectos de rendimiento es el "query time", que indica el
"round trip time" o tiempo de ida y vuelta que tomó la consulta, en milisegundos.

Y finalmente, el dato del tamaño del paquete de respuesta podría ser importante para
detectar posibles problemas con paquetes demasiado grandes. Hasta 512 es un
tamaño que debiera funcionar en cualquier tipo de red, pero en casos modernos uno
puede esperar que 1232 es una cantidad segura dentro de UDP sin fragmentar.

Capítulo 4: Resource Records más comunes, y algunos modernos.

En este segmento veremos los tipos de registros más comunes, y algunas de las
novedades de los últimos recién estandarizados.

Como se ha visto en secciones pasadas, cualquier nombre de dominio puede tener

cero o más RRs asociados. Cada RR tiene un tipo y clase, más el contenido propio

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

de su tipo, llamado "RDATA". Además, es posible tener registros repetidos con el
mismo nombre, tipo y clase, con distintos RDATA. En ese caso ante una consulta se
deben responder todos juntos en un "RRset".

Partimos por los mínimos que debe tener una zona de forma obligatoria, que se puede
decir que son registros "de infraestructura", en el sentido que no son normalmente
consultados por los clientes finales, sino que sirven para que los resolvers puedan
recorrer el árbol DNS.

Se trata de SOA, y NS.

El registro SOA ("start of authority") indica que el nombre donde se encuentra es el

ápex de una zona. Acá se indican datos que son útiles para los servidores autoritativos
secundarios, y datos temporales de caché. Se compone de los siguientes campos:

MNAME: indica el nombre del servidor primario para la zona, pero actualmente se
utiliza para definir el nombre hacia dónde se dirigen las actualizaciones automáticas
de registros, si se utiliza la técnica de "dynamic updates".

RNAME: email de contacto del administrador de la zona.

SERIAL: número que indica la "serie" de la zona. Cada vez que hay un cambio en el
contenido de la zona, el serial debe aumentarse. Lo utilizan los secundarios para
saber si hay cambios en el momento que deban refrescar la zona.

REFRESH: indica el número de segundos máximo que un servidor secundario de la

zona puede mantener su copia sin consultar al primario, para buscar actualizaciones.

RETRY: indica el número de segundos en que un secundario debe reintentar

contactar al primario, en caso de que no obtuviera respuesta.

EXPIRE: indica el número máximo de segundos en que un secundario puede

mantener la zona sin poder contactarse con el primario. Si se excede este tiempo, el
secundario debe dejar de responder por la zona, y dar RCODE SERVFAIL ante
consultas.

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

TTL: este número indica cuántos segundos se puede hacer caché de las respuestas
negativas (NXDOMAIN). Este es el único campo que es útil para un resolver. Ante
respuestas NXDOMAIN por una zona, el autoritativo debe agregar en el campo
AUTHORITY el SOA de la zona. Con este dato, un resolver puede mirar este TTL, y
almacenar el NXDOMAIN durante este tiempo.

Ahora vemos el otro RR que es requisito para cualquier zona, el NS, "name server".

Este se ubica en el ápex de la zona, e indica los nombres de los servidores de nombre
que son autoritativos para la zona. Como se contó en una sección anterior, este
registro también se encuentra repetido en la zona padre, y debe ser igual en ambos
lados. Lamentablemente eso no es así, y ocasiona diversos problemas de resolución.
Es importante siempre preocuparse de mantenerse sincronizados, y ante cualquier
modificación en el ápex, acudir al padre y cambiarlo además ahí.

El RDATA de un registro NS solamente tiene un nombre de host. Sin embargo, hay

que tener especial cuidado en el padre. Los NS que se encuentren ahí, deben además
incluir las direcciones IP de los nombres que son hijos de la misma zona. Estos
registros se llaman "glues", y son requisitos para que la resolución funcione. Cuando
un resolver recorre el árbol DNS, partiendo desde la raíz hacia abajo, y se topa con
una delegación a un nombre que está bajo la misma zona, no es posible que pueda
seguir su camino sin los glue records.

En el ejemplo vemos que la zona lacnic.net tiene como NS a ns.lacnic.net, entre otros.
Un resolver no puede averiguar la dirección IP de ns.lacnic.net por sí sola, porque no
sabe dónde ir a buscar esa delegación. Es por esto que el padre de lacnic.net, la zona
.net, al momento de responder con los NS de lacnic.net, debe incluir los glues de

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

ns.lacnic.net y ns2.lacnic.net en forma de registros A y AAAA en la sección
ADDITIONAL.

Ahora pasamos a los registros que ya son útiles para los clientes finales. Partimos
con los AAAA y A, que representan las direcciones IP versión 6 y versión 4,
respectivamente.

Una cosa importante que podemos mencionar acá, es que los registros individuales
que vienen dentro de un RRset, no tienen un orden predeterminado. Es decir, el orden
no significa nada, y de hecho es normal que un autoritativo responda con los registros
en distinto orden ante consultas repetidas. Una aplicación no puede asumir que el
orden de los registros signifique prioridad.

El registro MX indica el nombre del "mail exchanger" para el dominio, y se puede

publicar en los nombres de hosts como en el ápex. Un despachador de correos debe
consultar por el registro MX al nombre de dominio de la parte a la derecha de una
dirección de correo, pero si no lo encuentra, puede consultar al ápex de la zona, que
es donde normalmente se publica y tiene validez para todo el dominio.

El RDATA de un registro MX se compone de un número de prioridad, y de un nombre

de host.

El registro TXT es uno de los más abusados dentro del DNS. Esto porque en su
definición original, acá se podía poner "cualquier texto libre sin formato".

Lamentablemente, hoy el uso considera que una definición tan libre es un lugar ideal
para poner cualquier tipo de dato que se me ocurra. Es así como se ponen en registros
TXT claves para verificar la titularidad de un dominio, se ponen registros de
autenticación SPF para correos, llaves DKIM de autenticidad de dominio, etcétera.

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

El protocolo DNS es totalmente extensible, pero la forma correcta de incluir nuevos
campos, es justamente ¡crear nuevos tipos! No es muy complejo proponer un nuevo
tipo, darle la estructura deseada y enviarlo a IETF para su adopción. Pero
lamentablemente hay una tendencia a ahorrar trabajo y simplemente reusar los TXT.

El último tiempo se ha recomendado que si de todas formas se quiere utilizar un

registro TXT, que al menos no esté en el ápex sino en algún nombre especial dentro
de la zona, con un prefijo especial que lo haga inválido para hostnames normales, y
de esa forma evitar la colisión con registros normales.

El registro PTR es muy importante para operadores de redes, ya que es donde se

definen los reversos de las direcciones IP. Antiguamente en IPv4 se consideraba que
todas las direcciones debían tener su reverso, pero actualmente en IPv6 ya no es
necesario (¡ni tampoco recomendable!). Se estima que solo es necesario para ciertos
servicios que lo requieren por protocolo, o seguridad. Por ejemplo, los hostnames de
los MX y NS es razonable indicarles su reverso.

El qname del registro PTR se arma reversando los octetos de la dirección IPv4, o los
doble-bytes en la dirección IPv6, agregándole el sufijo in-addr.arpa en el caso de IPv4,
e ip6.arpa en IPv6. Esto lo veremos en detalle en un módulo siguiente.

Finalmente, otro de los registros más comunes es el CNAME, "canonical name".

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

Este registro tiene una peculiaridad especial: no se permite ningún otro RR en el
mismo nombre. Esto es así porque CNAME indica que el nombre es un "alias" hacia
un nombre "canónico", que es el que se pone en el RDATA. Entonces, es esperable
que un resolver "siga" ese CNAME, volviendo a repetir la pregunta con el mismo tipo
y clase, pero con el nombre canónico.

Un efecto secundario de esta regla es que en el ápex no puede haber un RR de tipo

CNAME, porque en el ápex es obligatorio tener SOA y NS. Esto ocasiona algunos
problemas cuando se quiere utilizar por ejemplo el "naked domain" en servicios de
CDN. Las CDN normalmente solicitan que en la etiqueta "www" se ponga un CNAME
apuntando a su dominio, pero esto es incompatible para el "naked domain" por la
regla anterior.

Además, hay otras reglas especiales como que no se permite que un nombre de host
use CNAME si está en los registros NS ni MX.

En este módulo veremos algunos registros más nuevos y complejos, pero que se
espera que cada vez sean más utilizados.

Partimos con el registro SRV, que permite ubicar "servicios". Aunque es bastante
antiguo nunca fue demasiado utilizado, solo unos pocos servicios se animaron a
usarlo. Incluso la gente de los navegadores web decidió crearse otro distinto, por
temas de formato.

El RDATA del tipo SRV es “Priority” “Weight” “Port” y “Target”.

La prioridad es una forma de ordenar los distintos RRs dentro de un set, similar al
registro MX, y un cliente debe siempre utilizar primero el que tiene el menor número
de prioridad.

Weight indica el peso que tienen distintos servidores con la misma prioridad, y se
debe utilizar al revés de la prioridad, el número más grande primero.

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

Luego viene el puerto donde se da el servicio, y el nombre de host donde se ubica.

Este RDATA debe asociarse a un nombre especial:” _Service._Proto.Name”. Por

ejemplo, si queremos tener un servidor jabber para el dominio lacnic.net, este registro
SRV se debe ubicar en el nombre “_xmpp-server._tcp.lacnic.net”.

Otros servicios que usan SRV son LDAP, y SIP.

El registro CAA es necesario para obtener certificados digitales, y debiera ser

obligatorio según las reglas de la Asociación de Autoridades Certificadoras. En este
registro debe indicarse qué Autoridades pueden otorgar certificados para el dominio,
y debiera ser respetado por todas ellas. No deberían emitir un certificado por un
dominio que no esté en el registro CAA.

El formato es: “CAA”, “flags”, “tags” y “value”, por ejemplo "CAA 0 issue
‘letsencrypt.org’", que indica que el dominio acepta certificados emitidos por
Let’sEncrypt.

El registro TLSA permite el despliegue de la tecnología "DANE", una de las

aplicaciones construidas sobre DNSSEC que permite entre otras cosas, dejar de
depender de las autoridades certificadoras para emitir certificados. En un registro
TLSA se encuentra el certificado o un hash del mismo que corresponde a un servicio.
Por ejemplo, en la comunicación de los servidores SMTP que despachan correo, es
posible crear un registro TLSA en los dominios receptores de correo que indique qué
certificado es el correcto al momento de iniciar una comunicación SMTP sobre TLS.
De esta forma, es posible dar seguridad que la conexión es la correcta, y no hay
interceptación de tráfico. La seguridad del correo descansa en la seguridad que otorga
DNSSEC al DNS.

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

Acá vemos un registro de ejemplo, que incluye un hash del certificado intermedio en
la conexión SMTP para el dominio example.com.

Este es uno de los más recientes registros, recién saliendo de IETF. Todavía no es
RFC, pero en estos meses ya debería estar listo. El registro HTTPS es como el
sucesor del anterior SRV, pero exclusivamente para web.

Este registro se asocia a un servicio web, y permite indicar distintos "puntos de

servicio" (por ejemplo una granja de servidores, en distintos puertos), puede indicarse
datos de transporte, y llaves para cifrar los mensajes de inicio. Además este registro
permite ponerse en el "ápex" de un dominio, permitiendo por fin el uso de alias en los
"naked names".

Por ejemplo, "HTTPS 1 . port=8002 alpn=h2,h3 ech=’123…’" indica que el servicio

web en ese nombre escucha en el puerto 8002, soporta HTTP/2 y HTTP3, y la llave
para cifrar los TLS Encrypted Client Hello es "123...".

Finalmente, indicamos los registros que se asocian con DNSSEC, que se verán con
mayor profundidad en un capítulo posterior. Pero solo como mención acá tenemos
los RRSIG que mantienen las firmas criptográficas, DNSKEY con las llaves de la zona,
y NSEC/NSEC3 con las cadenas que cubren los nombres "no existentes". Estos son
algunos de los más comunes y que se encuentran en todas las zonas firmadas con
DNSSEC.

Capítulo 5: DNSSEC, las extensiones de seguridad.

En este módulo veremos la teoría detrás de DNSSEC, las extensiones de seguridad
del DNS.

Las extensiones de seguridad al DNS, llamadas DNSSEC, fueron creadas en su

actual forma el año 2005 con los RFCs 4033, 4034 y 4035. Se hace uso de las
extensiones EDNS del año 1998, por lo que es requisito que EDNS esté habilitado en
el lado del servidor y del recursivo.

DNSSEC agrega 3 propiedades a los mensajes que antes no tenían: autenticidad, es

decir tener una certeza que el mensaje es originado por quien debiera ser; integridad,

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

que el mensaje no fue alterado; y negación de existencia auténtica: que se pueda
verificar además cuando un nombre no existe.

Para cumplir con estos objetivos, se agregó criptografía asimétrica a la estructura del
árbol DNS. Cada RR ahora tiene una firma criptográfica asimétrica, y mediante el uso
de llaves privadas y públicas se pueden crear estas firmas, y verificar que son
correctas.

Es el mismo esquema que se utiliza para los certificados digitales web. La gran
diferencia eso sí es que para distribuir las llaves no se utilizan Autoridades
Certificadoras, como es en el web, sino que se utiliza el mismo árbol jerárquico del
DNS.

¿Por qué se creó DNSSEC?

La situación que se quería mejorar era principalmente evitar los "envenenamientos de
caché", que fueron ataques que cada vez ocurrían más a menudo. En este ataque se
aprovechaba de la simpleza del protocolo UDP, y que existe muy poca seguridad
dentro del transporte.

Como vimos antes, lo único que protege a un cliente que hace una consulta es el
identificador del paquete, un número de 16 bits del encabezado, que es creado al azar
por el cliente y debe venir en la respuesta. Así, un cliente podría saber que la
respuesta viene del servidor que él consultó.

Sin embargo, este mecanismo pronto quedó obsoleto con redes y procesadores cada
vez más rápidos. Pronto se tuvo ataques reales donde un atacante podía "adivinar"
un ID, o bien enviar miles de combinaciones en pocos segundos, hasta adivinar el
correcto e insertar mensajes falsos, que el cliente no tiene forma de verificar.

Además, agregarle estas características al DNS permite seguir creciendo y

agregando información que por su naturaleza es importante que sea verificable, como
certificados digitales de correos, o llaves públicas de otros protocolos.

Un punto importante acá es que pese a que hay integridad y autenticidad, no hay
privacidad. Los mensajes que se intercambian en DNSSEC, al igual que en DNS, no

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

están cifrados, y cualquiera podría leerlos. El DNS es una base de datos pública y no
hay información confidencial, por lo que no se consideró que la privacidad fuera
importante.

Hagamos un pequeño repaso de criptografía asimétrica. Lo que se tiene acá es un

documento que Alicia le quiere transmitir a Borja. Además del documento, Alicia tiene
dos pares de llaves: una pública y otra privada. Ambas están matemáticamente
relacionadas entre sí, pero es muy difícil (casi imposible) calcular una de ellas si se
tiene la otra. Entonces Alicia se queda para sí misma con la llave privada, y comunica
su llave pública a todo el mundo.

Alicia, entonces, antes de mandar el documento, lo procesa matemáticamente con su

llave privada, y genera un trozo pequeño que se llama "firma", que envía junto con el
documento.

Borja, al recibir el documento junto con la firma, es capaz de verificar que es

matemáticamente correcta usando la llave pública de Alicia. Así está seguro que el
documento que tiene es el correcto. Ante cualquier modificación al documento, o bien
que alguien se haga pasar por Alicia y envíe otro; la firma no calzará y Borja podrá
detectar que hubo una intrusión, y descartará el documento.

Como vemos toda la seguridad del sistema depende de dos cosas muy importantes:
que Alicia guarde y proteja su llave privada; y que Borja reciba de una manera segura
la llave pública. Luego de eso, ya pueden intercambiarse mensajes sin problemas.

Queda el problema de la distribución de las llaves de forma segura. Como dijimos

antes, DNSSEC se aprovecha de la misma cualidad jerárquica del DNS para distribuir
las llaves dentro del mismo árbol, mediante una "delegación segura".

Veámoslo con un ejemplo. En el DNS plano, si un resolver quiere obtener la dirección

IPv6 de www.lacnic.net, recorre el árbol DNS desde la raíz, siendo delegado desde
ahí a .net, luego a lacnic.net, y finalmente obtiene la respuesta desde uno de los
servidores autoritativos, como por ejemplo ns.lacnic.net.

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

Lo que ocurre con DNSSEC es que ahora todos los resolvers de Internet, además de
tener configurados desde cero las direcciones IP de la raíz como siempre, ahora
tienen 1 llave pública criptográfica: la de la zona raíz. Entonces, ahora al consultar por
www.lacnic.net a la raíz, y recibir una respuesta con una delegación a .net, un resolver
que valide con DNSSEC además hará otra consulta por un nuevo registro que indica
si hay "delegación segura" y que contiene un resumen ("digest") de la llave pública de
.net. Y todo este nuevo registro está firmado con la llave de la raíz. El resolver
entonces puede verificar que la información es correcta, y sabrá que la zona hija .net
debe estar firmada, y usar una llave que calce con la indicada por el padre.

En seguida el resolver seguirá la delegación y consultará al servidor autoritativo de

.net, pero además de la respuesta a su consulta, hará también una pregunta por la
llave de la zona .net, que al verificar que corresponde al resumen que le dió el padre,
podrá almacenarla en su caché al igual que cualquier registro, obteniendo una
comprobación segura de la llave de .net.

De esta forma se va armando una "cadena de confianza" desde la raíz hacia abajo,
desde padres a hijos.

Llegó el momento de identificar estos nuevos registros asociados con DNSSEC.

Primero tenemos las firmas que son parte de todos los RRs. Estas se mantienen en
los registros RRSIG, y son enviados por los autoritativos en la misma sección
ANSWER de la respuesta.

Una cosa importante es que los RRSIG acompañan a los registros autoritativos de la
zona. Esta distinción es importante porque en el caso de las delegaciones de padres
a hijos, los registros NS no llevan firmas, porque el autoritativo es el hijo, donde sí se
encuentran firmas. Lo mismo pasa con los registros glues.

Los campos del RRSIG incluyen el tipo de están cubriendo, algoritmo, la llave con que
fue firmada identificada por su "tag", y la firma finalmente codificada en Base64; entre
otros campos.

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

Las llaves son por zona, por lo que se encuentran en el ápex correspondiente. Los
registros se llaman DNSKEY, y pronto veremos que pueden ser múltiples llaves que
se derivan entre ellas.

Entre los campos importantes se encuentra el Algoritmo de la llave, y su

representación en Base64.

Finalmente, la cadena de delegación del padre se forma mediante el registro DS, que
el padre debe mantener junto a los NS con los que delega la subzona.

Entonces, ¿cómo hace una zona para comenzar a utilizar DNSSEC?

Debe seguir los siguientes pasos:

1. crear sus propias llaves públicas y privadas;

2. poner la llave pública dentro de la zona, en un registro DNSKEY en el ápex;
3. con la llave privada, firmar todos los registros de la zona y crear registros RRSIG;
4. enviar un resumen (digest) de su llave pública a su padre, usando normalmente el
mismo mecanismo como envía sus NS;
5. el padre agrega un registro DS con este resumen, además de los NS, para el
nombre del hijo; y a su vez firma este DS con su propia llave privada, en un RRSIG
de este DS.

Con esto, ya cualquiera puede verificar los RRs de la zona hija, porque puede pedir
las llaves al hijo con sus registros DNSKEY, y verificarlas con el registro DS del padre
que ya viene verificado.

Por último, hay una cosa que no hemos mencionado. ¿Cómo verificamos que un
nombre que no existe es una respuesta verdadera?

Para esto se inventó un nuevo mecanismo llamado NSEC: negación segura. En el

caso del DNS plano, cuando un servidor autoritativo recibía una consulta por un
nombre inexistente, respondía con el rcode NXDOMAIN, y el SOA en la sección de
autoridad, para conocer el TTL de esa negación.

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

Con DNSSEC, la forma de indicar que un nombre no existe es mostrar el rango en
que un nombre "debería ir", y asegurar que ahí no hay nada.

Veámoslo con un ejemplo.

Si un resolver le pregunta a un autoritativo por el nombre "noexiste.lacnic.net", el

autoritativo le responderá con un RCODE NXDOMAIN como antes, pero este RCODE
va en el header y no está protegido por DNSSEC. Lo que hace además es responderle
un registro NSEC que dice "entre el nombre mail.lacnic.net y www.lacnic.net no hay
nada", respuesta que sí va firmada. Entonces el resolver puede verificar este NSEC,
y además deducir que no hay un nombre "noexiste.lacnic.net", porque en orden
alfabético tendría que estar en ese rango inexistente.

Para que esta técnica funcione hubo que definir un orden canónico de la zona, y los
autoritativos ahora al firmar sus registros, además de poner los DNSKEY y RRSIG,
deben ordenar la zona, armar la cadena de NSEC con todos los espacios, y firmarlos.

El registro NSEC3 es otra versión de NSEC que permite no firmar la cadena completa
de nombres, además que los oculta mediante una técnica de cifrado. No es
recomendable usarlo porque agrega complejidad al procesamiento criptográfico en el
firmado y validación, además que no es completamente seguro porque esos espacios
sin firmar permitirían insertar registros falsos. Se inventó pensando en TLDs gigantes
como .com, que tiene cientos de millones de registros, y era muy caro firmar todo
.com desde un comienzo, mientras hubiera muy pocos hijos de .com firmados. En la
actualidad se recomienda que todas las zonas normales utilicen NSEC.

Hay otras decisiones que cada administrador de zona debe tener. En criptografía hay
varios algoritmos que se pueden utilizar para firmas. Por ejemplo, tenemos RSA,
curvas elípticas, GOST, Edwards-curve. Además, las llaves pueden tener distinto
"largo", que representa el tamaño de bits e influye en el grado de protección, pero que

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

aumentan de tamaño el paquete de respuesta. Se recomienda ojalá que el paquete
de respuesta en cualquier registro quepa dentro de 1220 bytes.

Por último, los resúmenes de los DS también tienen distintas alternativas, como
SHA256, SHA384, etc.

En este tipo de decisiones, lo recomendable es seguir las recomendaciones de los

desarrolladores de software y operadores. Al usar los algoritmos más avanzados se
corre el riesgo de tener poco soporte. ¡No sirve de mucho usar las llaves más
avanzadas si nadie podrá validarlas!

Uno de los cambios más grandes al usar DNSSEC es que se le agrega la variable
temporal absoluta al DNS. Anteriormente en el DNS en plano, uno podía definir una
zona, publicarla en el DNS, y dejarla ahí funcionando por años. Los únicos valores
temporales son relativos, los TTL. Ahora con DNSSEC, ya no es posible tener una
zona estática por años. Las firmas tienen una validez temporal absoluta, un día y hora
precisa al segundo, y antes que expiren es necesario refirmarlas. Las llaves también
se recomienda tenerlas publicadas solo por un tiempo, y es importante irlas
cambiando por unas nuevas, proceso llamado rotación de llaves.

Estos procedimientos están automatizados en todos los softwares modernos de DNS,

pero es importante estar atentos a eso. Monitorear las zonas, preocuparse de que los
demonios estén funcionando, actualizar los sistemas. No es algo distinto a cualquier
servicio de Internet, pero antiguamente se tenía la costumbre de dejar al DNS como
un servicio abandonado, y eso ya no va más.

Acá vemos el formato del registro RRSIG, que mantiene las firmas. Tiene dos campos
de tiempo absoluto: la fecha de incepción y la fecha de expiración. Ambas definen
desde cuándo y hasta cuándo se pueden utilizar estas firmas. Uno de los errores más
típicos al comienzo de usar DNSSEC es dejar expirar las firmas. Una vez que las
firmas están expiradas, ya ningún resolver podrá validar los registros, por lo que la
zona deja de funcionar.

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

En este caso, esta firma tiene validez hasta el 29 de junio de 2022, a las 11:52:29
UTC.

Por esto, debe existir un proceso que regularmente vaya refirmando la zona,
actualizando las firmas. Todos los software de DNS tienen esta característica de
forma interna.

Por otro lado, también es importante ir rotando las llaves de forma regular. Esto es
porque las llaves criptográficas pueden ser objetivo de ataques de fuerza bruta, donde
un atacante intenta quebrarlas. Este proceso toma un tiempo, por eso es importante
que una zona vaya cambiando sus llaves y hacer inefectivo este ataque. Para hacer
la rotación correctamente sin quebrar la cadena de confianza, hay que ser cuidadoso.
El proceso es como se indica acá, partiendo de una zona originalmente firmada con
una llave:

1. se crean nuevas llaves;

2. se agrega la nueva llave al DNSKEY set, la cual es firmada por la llave antigua;
3. esto se deja publicado por un tiempo suficiente para que todos los resolvers sean
capaces de conocer la nueva llave, y darle validez;
4. una vez pasado ese tiempo, la nueva llave empieza a firmar la zona; y
5. ya es seguro eliminar la llave antigua.

De nuevo todo este proceso es manejado automáticamente por los softwares de DNS.
Solo es necesario que el operador defina algunos parámetros, como el tiempo que
desea que se mantengan las llaves vivas antes de rotarlas.

Acá aprovechamos de contar de otra técnica de DNSSEC que hace más fácil la
rotación.

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

Si recuerdan, el padre debe tener el hash de la llave del hijo. Si las rotamos todo el
tiempo, eso significaría que ¡tendríamos que estar avisando al padre cada vez que
cambiamos la llave! Muchas veces esto es impracticable, porque la comunicación con
el padre es compleja y no automatizable. Por eso, se inventó la técnica de separar las
llaves en dos tipos. Una se llamó la "KSK", por "key signing key" ("llave que firma
llaves"); y la llave "ZSK", "zone signing key" ("la llave que firma zonas"). De esta forma,
la llave KSK es la que se manda al padre, y dura mucho más (del orden de años), por
lo que se elige un algoritmo más grande y fuerte. Y, por otro lado, se crea una llave
ZSK que es más débil y pequeña, pero que esta es la que firma la zona, y se puede
rotar más a menudo (del orden de meses).

La KSK firma el DNSKEY set, donde está la ZSK. De esta forma, uno puede ir rotando
las ZSK en forma independiente, sin molestar al padre; y solo pasados unos años,
cuando sea necesario rotar la KSK, hay que comunicarla al padre.

Por último, algunas advertencias finales sobre DNSSEC:

1. No entrega privacidad, porque no fue parte del problema original.

2. Fue diseñado para proteger el camino entre autoritativos y recursivos, no al cliente

final. Siempre se pensó que el cliente final no debía hacer validación, porque este
delega esa función al recursivo, el cual es de su confianza. Sin embargo, hay algunos
planes de comenzar a hacer validación en el cliente final, que requerirían algunos
ajustes futuros.

3. Hace más delicado al DNS, en el sentido que ahora es posible quedar fuera de
Internet por problemas de validez de firmas, o de rotaciones mal hechas. Pero es el
compromiso que hay que tomar al darle seguridad al DNS. Y actualmente todos los
software modernos tienen automatizado todos estos procesos, sin mayor intervención
humana.

4. De vez en cuando hay que actualizar los algoritmos, a medida que van quedando
obsoletos. Desde que se lanzó DNSSEC en forma global, ya se declaró obsoleto SHA-
1 para los DS, y las llaves de largo menor a 1024 en RSA. Es importante estar atentos
a estos cambios e ir actuando. De nuevo, son los mismos desarrolladores de software

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

que van implementando estos cambios en sus sistemas, avisando a los
administradores DNS.

Es importante tener en cuenta los límites de DNSSEC, para no caer en confianzas

excesivas. Por supuesto que vale la pena usar DNSSEC, y cada vez será más
inevitable, a medida que queramos utilizar otras técnicas que dependen de él. Es una
tecnología probada y en operación en gran parte de Internet, y es parte de la
responsabilidad que cualquier operador tiene con la sanidad y seguridad del
ecosistema.

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