Despliegue de DNSSEC en la región - Estadística y mediciones
Por: Hugo Salgado (@huguei) / Dario Gomez (@daro_ua) / Alejandro Acosta (@ITandNetworking)
Introducción
En el presente post queremos conversar sobre unas recientes investigaciones que hemos realizados
sobre un tema que nos apasiona mucho: DNSSEC. Por favor notar que hablamos en plural:
“investigaciones”, debido a que son dos estudios sobre DNSSEC que comenzamos a la vez…
¡favor continua leyendo para que entiendas de que se tratan ambas dos!
Sobre DNSSEC
DNSSEC añade un plus de seguridad al protocolo DNS que permite comprobar la integridad
y autenticidad de los datos, previniendo ataques de suplantación y falsificación, mediante
el uso de criptografía asimétrica o mejor conocida como clave pública / privada.
Mediante el uso de estas claves y las firmas generadas a partir de ellas, se puede saber
si una consulta fue modificada, permitiendo garantizar la integridad y autenticidad del
mensaje. Si al comprobar estas firmas no coinciden entre ellas, quiere decir que la cadena
de confianza se ha roto y la consulta no puede ser validada como legítima.
Contar con DNSSEC depende del ISP o del proveedor de servicios de internet que tenga
contratado, que es quien debe configurarlo. Para saber si cuenta con DNSSEC existen varias
herramientas en Internet que lo permiten como:
https://dnssec-analyzer.verisignlabs.com/
Como muchos saben DNSSEC es un protocolo que ha venido creciendo mucho en los
últimos años. Dos aspectos han marcado su aumento del despliegue:
1) DNSSEC viene habilitado por defectos en algunos servidores recursivos (BIND) y
2) Grandes avances en facilitar habilitar DNSSEC en los diferentes dominios por los
registradores más importantes.
3) Todos los grandes recursivos públicos hacen validación DNSSEC (google public dns,
cloudflare, quad9, etc)
4) Apple acaba de mencionar que iOS16 y macOS Ventura permitirán hacer validación
DNSSEC en el stub final.
DNSSEC ha sido un tema muy importante para LACNIC, hemos realizado gran cantidad
de eventos y actividades en torno a este tema, sin embargo hasta la fecha no teníamos
ningún estudio propio al respecto.
¿De qué trata el estudio?
Desde el área I+D de LACNIC quisimos realizar un estudio con el fin de conocer el estado
y el avance respecto al despliegue de DNSSEC en la región.
Origen de la Data
Tenemos dos fuentes de datos muy confiables
Utilizamos los probes ATLAS de RIPE https://atlas.ripe.net/
Realizamos capturas (tcpdump) que posteriormente fueron anonimizadas en
servidores autoritativos
Fechas:
La obtención de la data comenzó en Noviembre de 2021, actualmente se lleva a cabo de
una manera automatizada con reportes semanales y mensuales [1]
¿Cómo se identifica que un servidor realice DNSSEC?
Hay que verlo desde dos aspectos:
Sondas Atlas:
Se envían solicitudes de resolución DNS a todas las sondas disponibles en latinoamérica y el caribe, por un nombre de dominio que intencionalmente tiene sus firmas incorrectas y por lo tanto no valida según DNSSEC. Si la respuesta es error (SERVFAIL), quiere decir que el resolver que utiliza esa sonda sí utiliza correctamente DNSSEC. Si por el contrario se obtiene respuesta (NOERROR), quiere decir que dicho resolver no realiza ninguna validación. Nótese que interesantemente la idea es que la respuesta del servidor DNS sea negativa, *esto es la clave* para saber si el recursivo valida DNSSEC o no.
Te dejamos este ejemplo: si visitas dnssec-failed.org y puedes abrir la página significa que tu DNS recursivo no hace DNSSEC, si no la puedes abrir es bueno! :-).
Captura (tcpdump):
Antes de indicar que hacemos con la captura vamos a expandir un poco el concepto de DNSSEC. Así como existen los registros tradicionales en DNS (A, AAAA, MX, etc) para la utilización de DNSSEC se agregaron nuevos registros, estos mismos son DS, RRSIG, NSEC, NSEC3 y DNSKEY. Es decir, un servidor DNS recursivo puede consultar el registro AAAA para conocer la dirección IPv6 de un registro y puede consultar el registro DS (Delegation Signer) para verificar la autenticidad de las zonas hijas. La parte clave de este estudio es que los servidores que no hacen validaciones DNSSEC no consultan registros DNSSEC!.
En base a lo anterior, al momento de realizar la captura se le pide a tcpdump que tome todo el paquete (flag -s 0), de esa manera tenemos todo el contenido del mismo, desde capa 3 hasta capa 7, durante el procesamiento del paquete buscamos por los registros específicos de DNSSEC (nuevamente: DS, RRSIG, NSEC, NSEC3 y DNSKEY), si conseguimos alguno de ellos entonces el recursivo si hace DNSSEC, en caso contrario no hace.
¿Donde se realiza la captura mencionada?
La captura se hace especificamente en una de las instancias del servidor DNS
Reverso D (D.IP6-SERVERS.ARPA). El comando utilizado es: /usr/sbin/tcpdump
-i $INTERFAZ -c $CANTIDAD -w findingdnssecresolvers-$TODAY.pcap -s 0 dst port
$PORT and ( dst host $IP1 or dst host $IP2 )
Procesamiento de la información
Primero, el procesamiento de los datos consta de varias partes, todas realizadas
completamente con software Open Source, específicamente con Bash, Perl y Python3
sobre Linux.
Segundo, recordemos que existen dos fuentes de información: Captura de tráfico (PCAPs)
y Probe Atlas. Aquí la metodología seguida en cada caso:
a) Procesamiento de los PCAPs: Luego de obtener los PCAPs se realizan una serie de
paso, entre ellos:
1) El procesamiento de los .pcap se realiza en Python3 utilizando la librería pyshark.
2) Limpieza de los datos improcesables (paquetes malformados, dañados, no-procesables, etc)
3) Remoción de direcciones duplicadas
4) Anonimización de datos
5) Generación de resultados
6) Generación de las gráficas y open data
b) Procesamiento de la información obtenida en RIPE Atlas:
La captura de datos se realiza con mediciones mensuales en la plataforma RIPE Atlas,
utilizando su API por línea de comandos. Luego se recogen y procesan en una serie de
scripts utilizando lenguaje Perl, para finalmente graficar utilizando la API de Google Charts
y adicionalmente dejamos los datos disponibles siempre en Open Data.
Favor recordemos que para detectar si una sonda está utilizando un resolver con validación,
se utiliza un nombre de dominio que intencionalmente tiene sus firmas incorrectas. De
esta forma, al intentar resolver ese nombre, una sonda que valide debe responder con error,
porque el nombre no es válido según DNSSEC. Por el contrario, si se obtiene una respuesta
positiva frente al nombre, quiere decir que el resolver no está validando, ya que ignoró la
firma incorrecta.
Resultados obtenidos
Esta gráfica muestra la cantidad de servidores estudiados que utilizan DNSSEC y cuáles no
lo usan. Las líneas azules determinan los servidores con DNSSEC activo, las rojas los que
no lo tienen.
Grafico 1
Se puede apreciar que para el 2 de Junio 2022 existen más servidores recursivos sin realizar
DNSSEC que los que lo hacen. Se analizaron entre 33.000 a 55.000 direcciones IP cada semana.
En líneas generales, se mantiene un promedio aproximado de un 55% de servidores que no utilizan
el protocolo y un 45% de muestras positivas.
En el gráfico #2 podemos apreciar el histórico de consultas DNSSEC en IPv6. Un dato no menor
que llama mucho la atención es que en varios periodos de muestreo, existen más cantidad de
consultas DNSSEC sobre v6 que en v4. Indiscutiblemente la intención es que la línea roja
disminuya y la azul aumente de forma gradual.
Ranking de países con mayor validación DNSSEC
Utilizando la plataforma de mediciones de RIPE Atlas, es posible medir en cada una de ellas su
capacidad de validar DNSSEC o no. Cada medición se puede agrupar por país, creando un ranking:
Ranking ordenado con el porcentaje de validación DNSSEC promedio desde redes de países
en Latinoamérica y el Caribe correspondiente a mayo de 2022.
Los números dentro de las barras indican la cantidad de ASs participantes por cada país. Se
descartan países donde medimos un solo ASs.
Resumen
Desde el estudio basado en captura de tráfico, con los datos obtenidos en un lapso de 8
meses la gráfica sugiere una disminución lenta de número de servidores NO-DNSSEC;
adicionalmente parece existir un mayor despliegue de DNSSEC en servidores IPv6 que en IPv4.
En el caso del análisis de sondas Atlas, es esperable un mayor despliegue de validación que
con otras fuentes de datos más genéricas, considerando que las sondas generalmente son
hospedadas en redes más avanzadas o por usuarios que podrían activar deliberadamente
DNSSEC. Pero representa de alguna manera el “límite superior” de penetración, y también
es un indicador importante de la evolución a través del tiempo.
OpenData
Como es habitual en LACNIC siempre deseamos dejar nuestra información disponible para su
trabajo por quien así lo desee:
https://stats.labs.lacnic.net/DNSSEC/opendata/
https://mvuy27.labs.lacnic.net/datos/
Estos datos que estamos dejando disponibles también poseen el espíritu de “Time Series
Data”. Es decir, estamos dejando los datos recolectados durante el tiempo lo que hará muy
sencillo tener fluctuaciones de nuestras estadísitcas en el tiempo y saber si el despliegue de
DNSSEC aumenta y/o disminuye por país, región, etc.
Como siempre cuando realizamos este tipo de proyectos, son bienvenidas sugerencias de
mejora tanto en la implementación como en la visualización de la información obtenida.
Referencias:
[1] https://stats.labs.lacnic.net/DNSSEC/dnssecstats.html
https://mvuy27.labs.lacnic.net/datos/dnssec-ranking-latest.html
No hay comentarios:
Publicar un comentario
¿Algo adicional que quieras mencionar? ¿Algun consejo?, ¿truco? Gracias!