lunes, 25 de julio de 2022

Despliegue de DNSSEC en la región - Estadística y mediciones

 

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/

https://dnsviz.net/

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.

Nro de Servidores DNSs estudiados

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.

Nro de Servidores IPv6 DNSs estudiados

Grafico #2


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 DNSSEC por pais

Grafico #3

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!

Despliegue de DNSSEC en la región - Estadística y mediciones

  Despliegue de DNSSEC en la región - Estadística y mediciones   dnssec   mediciones Por: Hugo Salgado (@huguei) / Dario Gomez (@daro_ua) / ...