zmap/zdnsBiblioteca de consulta DNS rápida y herramienta CLI
ZDNS es un resolvedor DNS de alta velocidad y una utilidad de línea de comandos para realizar mediciones DNS a gran escala. ZDNS está escrito en Go y contiene su propio código de resolución recursiva y una caché optimizada para realizar consultas de un conjunto diverso de nombres. Usamos https://github.com/zmap/dns para construir y analizar paquetes DNS sin procesar. Para obtener más información sobre la arquitectura y el rendimiento de ZDNS, consulte el siguiente artículo presentado en la Conferencia de Medición de Internet del ACM '22.
[!TIP] La Wiki de ZDNS contiene información adicional sobre ZDNS y explica casos de uso y ejemplos.
ZDNS se puede instalar clonando el repositorio y ejecutando make install.
git clone https://github.com/zmap/zdns.git
cd zdns
make install
ZDNS consiste en una biblioteca de resolvedor recursivo biblioteca y un envoltorio CLI CLI.
La biblioteca consta de una estructura ResolverConfig que contendrá todas las opciones de configuración para todas las consultas realizadas. La ResolverConfig se utiliza para crear 1+ estructuras Resolver que realizarán todas las consultas. Un Resolver solo debe realizar una consulta a la vez (no es seguro para hilos) y se deben usar múltiples estructuras Resolver para el paralelismo. Consulte nuestros ejemplos para saber cómo usar la biblioteca. Los módulos se utilizan para definir el comportamiento de las consultas.
ZDNS proporciona varios tipos de módulos:
Módulos DNS sin procesar proporcionan la respuesta DNS sin procesar del servidor similar a dig, pero en JSON. Hay un módulo para (casi) cada tipo de registro DNS
Módulos de consulta proporcionan respuestas más útiles cuando se requieren múltiples consultas (por ejemplo, completar una consulta A adicional para direcciones IP si se recibe un NS en NSLOOKUP)
Módulos varios proporcionan otros medios adicionales para consultar servidores (por ejemplo, bind.version)
Detallamos los módulos a continuación:
Los módulos A, AAAA, AFSDB, ANY, ATMA, AVC, AXFR, BINDVERSION, CAA, CDNSKEY, CDS, CERT, CNAME, CSYNC, DHCID, DMARC, DNSKEY, DS, EID, EUI48, EUI64, GID, GPOS, HINFO, HIP, HTTPS, ISDN, KEY, KX, L32, L64, LOC, LP, MB, MD, MF, MG, MR, MX, NAPTR, NID, NINFO, NS, NSAPPTR, NSEC, NSEC3, NSEC3PARAM, NSLOOKUP, NULL, NXT, OPENPGPKEY, PTR, PX, RP, RRSIG, RT, SVCBS, MIMEA, SOA, SPF, SRV, SSHFP, TALINK, TKEY, TLSA, TXT, UID, UINFO, UNSPEC y URI proporcionan la respuesta DNS sin procesar en formato JSON, similar a dig.
Por ejemplo, el comando:
echo "censys.io" | zdns A
devuelve:
{
"name": "censys.io",
"results": {
"A": {
"data": {
"additionals": [
{
"flags": "",
"type": "EDNS0",
"udpsize": 512,
"version": 0
}
],
"answers": [
{
"answer": "104.18.10.85",
"class": "IN",
"name": "censys.io",
"ttl": 300,
"type": "A"
},
{
"answer": "104.18.11.85",
"class": "IN",
"name": "censys.io",
"ttl": 300,
"type": "A"
}
],
"protocol": "udp",
"resolver": "[2603:6013:9d00:3302::1]:53"
},
"duration": 0.285295416,
"status": "NOERROR",
"timestamp": "2024-08-23T13:12:43-04:00"
}
}
}
Las respuestas DNS sin procesar a menudo no proporcionan los datos que desea. Por ejemplo, una respuesta MX puede no incluir los registros A asociados en la sección adicional, lo que requiere una consulta adicional. Para abordar esta brecha y proporcionar una interfaz más amigable, también proporcionamos varios módulos de consulta: alookup, mxlookup y nslookup.
alookup actúa de manera similar a nslookup y seguirá los registros CNAME.
mxlookup adicionalmente realizará una consulta A para las direcciones IP que correspondan con un registro de intercambio.
nslookup adicionalmente realizará una consulta A/AAAA para las direcciones IP que correspondan con un registro NS.
Por ejemplo,
echo "censys.io" | zdns mxlookup --ipv4-lookup
devuelve:
{
"name": "censys.io",
"results": {
"MXLOOKUP": {
"data": {
"exchanges": [
{
"class": "IN",
"ipv4_addresses": [
"209.85.202.27"
],
"name": "alt1.aspmx.l.google.com",
"preference": 5,
"ttl": 300,
"type": "MX"
},
{
"class": "IN",
"ipv4_addresses": [
"142.250.31.26"
],
"name": "aspmx.l.google.com",
"preference": 1,
"ttl": 300,
"type": "MX"
}
]
},
"duration": 0.154786958,
"status": "NOERROR",
"timestamp": "2024-08-23T13:10:11-04:00"
}
}
}
ZDNS también admite consultas DNS especiales de "depuración". Los módulos incluyen: BINDVERSION.
ZDNS admite proporcionar entrada en una variedad de formatos según el comportamiento deseado.
La entrada más básica es una lista de nombres separados por nuevas líneas. Por ejemplo:
Desde stdin:
echo "google.com\nyahoo.com" | zdns A
cat list_of_domains.txt | zdns A
Desde un archivo
zdns A --input-file=list_of_domains.txt
Si no necesita resolver muchos dominios, se admite proporcionar el dominio como argumento CLI, similar a dig, para facilitar su uso.
Por ejemplo:
zdns A google.com --name-servers=1.1.1.1
Equivalente a dig -t A google.com @1.1.1.1
Normalmente, ZDNS elegirá un servidor de nombres aleatorio para cada consulta de dominio de --name-servers. Si en su lugar desea especificar
un servidor de nombres diferente para cada dominio, puede hacerlo proporcionando pares domainName,nameServerIP separados por nuevas líneas.
Esto anulará cualquier servidor de nombres proporcionado con --name-servers.
Por ejemplo:
echo "google.com,1.1.1.1\nfacebook.com,8.8.8.8" | zdns A
Puede ver que el resolver es el especificado para cada dominio en la salida (adicionales/respuestas omitidos por brevedad):
$ echo "google.com,1.1.1.1\nfacebook.com,8.8.8.8" | zdns A
{"name":"google.com","results":{"A":{"data":{"additionals":...,"answers":[...],"protocol":"udp","resolver":"1.1.1.1:53"},"duration":0.030490042,"status":"NOERROR","timestamp":"2024-09-13T09:51:34-04:00"}}}
{"name":"facebook.com","results":{"A":{"data":{"additionals":[...],"answers":[...],"protocol":"udp","resolver":"8.8.8.8:53"},"duration":0.061365459,"status":"NOERROR","timestamp":"2024-09-13T09:51:34-04:00"}}}
Los archivos de zona (de ICANN CZDS o similares) se pueden utilizar como fuente de entrada para ZDNS con el indicador --zone-file. Esto permite analizar archivos de zona desde stdin (predeterminado) o desde un archivo con el indicador --input-file.
De forma predeterminada, ZDNS extraerá solo el nombre de cada registro del archivo de zona. Si también desea resolver los nombres referenciados en la sección de respuesta de tipos de registro como CNAME o NS, puede usar el indicador CLI --zone-file-include-targets.
Por ejemplo, con --zone-file-include-targets y esta entrada de archivo de zona:
example.com. 3600 IN NS ns1.example.com
se resolverían tanto example.com como ns1.example.com.
ZDNS también admite pasar "desencadenadores" por línea de entrada que asignan líneas de entrada a módulos específicos. Con ellos, puede especificar que ciertos dominios se consulten con módulos específicos.
El formato de entrada es:
domain_name,name_server,trigger,trigger_2,etc, donde nameServer puede estar vacío para usar los servidores de nombres predeterminados y se pueden especificar 1+ desencadenadores.
Un archivo input.csv de ejemplo:
example.com,,a-trigger
google.com,,a-trigger,cname-trigger
example.com,1.1.1.1,aaaa-trigger
yahoo.com
apnews.com,1.1.1.1
Y el correspondiente multiple.ini:
; Especificar opciones globales aquí
[Application Options]
iterative=true
prefer-ipv6-iteration="true"
; Listar módulos y sus respectivas opciones específicas del módulo aquí. Un módulo solo se puede listar una vez
[A]
trigger = "a-trigger"
[AAAA]
trigger = "aaaa-trigger"
[CNAME]
trigger = "cname-trigger"
Esto consultará:
example.com con el módulo A usando servidores de nombres predeterminadosgoogle.com con los módulos A + CNAME usando servidores de nombres predeterminadosexample.com con el módulo AAAA usando el resolvedor 1.1.1.1 de Cloudflareyahoo.com con todos los módulos especificados y usando servidores de nombres predeterminadosapnews.com con todos los módulos especificados y usando el resolvedor 1.1.1.1 de CloudflareEjecutando el comando:
zdns MULTIPLE --multi-config-file="./multiple.ini" --input-file="input.csv"
ZDNS puede operar contra un resolvedor recursivo (por ejemplo, un servidor DNS organizacional) [comportamiento predeterminado] o puede realizar su propia recursión internamente. Si está realizando un número pequeño de consultas (es decir, millones) y utiliza menos de 10,000 gorutinas, normalmente es más rápido usar uno de los resolvedores recursivos comunes como Cloudflare o Google. Cloudflare es casi siempre más rápido que Google. Esto es particularmente cierto si está consultando nombres populares porque están en caché y se pueden responder en un solo viaje de ida y vuelta. Cuando se utilizan decenas de miles de hilos concurrentes, considere realizar la iteración internamente para evitar saturar o limitar la tasa de su resolvedor recursivo.
Para realizar recursión local, ejecute zdns con el indicador --iterative. Cuando se utiliza este indicador, ZDNS rotará entre los servidores raíz publicados (por ejemplo, 198.41.0.4). En modo iterativo, puede controlar el tamaño de la caché local especificando --cache-size y el tiempo de espera para iteraciones individuales configurando --iteration-timeout. El indicador --timeout controla el tiempo de espera de toda la resolución para una entrada determinada (es decir, la suma de todos los pasos iterativos).
El rendimiento de ZDNS proviene de la paralelización masiva utilizando gorutinas ligeras de Go. Esta arquitectura tiene varias advertencias:
Cada gorutina utiliza su propio socket de red dedicado. Por lo tanto, debe poder abrir tantos sockets (tanto en términos de descriptores de archivo máximo como de puertos efímeros) como hilos especificados (mediante --threads). De forma predeterminada, ZDNS utiliza 1,000 hilos, que es menos que el número máximo predeterminado de 1024 FD abiertos de Linux. Sin embargo, es mayor que el valor predeterminado de 256 de Mac OS. Puede ver el número máximo de FD abiertos (y por lo tanto sockets) permitidos ejecutando ulimit -n. Si desea ejecutar con un número de hilos mayor que este número, debe aumentar el número de archivos abiertos a nivel del sistema operativo. Si no lo hace, encontrará un error fatal similar a FATA[0000] unable to create socketlisten udp <client IP address>:0: socket: too many open files. Si desea ejecutar más hilos de los puertos efímeros disponibles, necesitará usar múltiples direcciones IP de cliente: --local-addr=A,B,C.
De forma predeterminada, ZDNS "reutiliza" sockets UDP creando un socket UDP no vinculado para cada rutina ligera al inicio y usándolo para todas las consultas (independientemente de la IP de destino). Esto mejora drásticamente el rendimiento porque ZDNS y el sistema operativo anfitrión no necesitan configurar y desmontar un socket para enviar cada paquete individual (ya que las consultas/respuestas DNS tienden a ser un paquete cada una). Sin embargo, esto significa que ZDNS preasignará un socket para cada hilo al inicio. Esto puede no ser óptimo si solo está consultando un número pequeño de nombres. Por ejemplo, si solo necesita consultar 100 nombres, pero usa los 1,000 hilos predeterminados, vinculará pero nunca usará 900 sockets UDP. En lugar de preocuparse por reciclar sockets, recomendamos que especifique un número razonable de hilos para su caso de uso (ya que esto también evita cualquier trabajo para iniciar esos hilos en primer lugar). Sin embargo, por eso puede obtener un error sobre la imposibilidad de abrir una gran cantidad de sockets aunque solo esté consultando un solo nombre. Si es importante crear un socket nuevo para cada consulta, puede deshabilitar esta reutilización especificando --recycle-sockets=false.
Gran parte del rendimiento que verá depende de su flujo de trabajo, hardware y de cuántos servidores de nombres se distribuye la carga. Si busca maximizar el rendimiento para su flujo de trabajo/hardware, recomendamos comenzar con 100 hilos y aumentar hasta que comience a ver un aumento en los fallos de resolución de nombres. Para ayudar con esto, puede usar --output-file=output.jsonl y grep -v "NOERROR" output.jsonl | wc -l para contar el número de nombres que fallaron al resolver. Los indicadores que pueden ser útiles para ajustar el rendimiento son:
--timeout La cantidad máxima de tiempo que ZDNS dedicará a un solo nombre--iteration-timeout La cantidad máxima de tiempo que ZDNS dedicará a un solo paso de iteración (ej: resolver google.com en la capa .com)--network-timeout La cantidad máxima de tiempo que ZDNS esperará una respuesta de un servidor de nombres--retries=N Si una conexión a un servidor de nombres específico falla en --iterative, ZDNS reintentará con otro servidor de nombres no consultado en esa capa. Los reintentos son por nombre, por lo que si --retries=1, ZDNS reintentará un nombre contra un nuevo servidor de nombres una vez durante su proceso de iteración completo. Si todos los servidores de nombres han sido consultados, se elegirá un servidor de nombres aleatorio.--name-servers La lista de servidores de nombres a usar para las consultas, útil principalmente con --iterative=falseDNS incluye muchos datos extraños que no siempre son útiles. Hay cuatro niveles de verbosidad de resultados: short, normal (predeterminado), long y trace:
short: Short es la salida de resultados más concisa. Contiene solo información sobre las respuestas.normal: Normal proporciona todo lo incluido en short, así como datos sobre el servidor que responde.long: Long muestra todo lo que el servidor incluyó en el paquete DNS, incluidas las banderas.trace: Trace muestra todo de cada paso del proceso de recursión.Los usuarios también pueden incluir campos adicionales específicos usando el indicador --include-fields y especificando una lista de campos, por ejemplo, --include-fields=flags,resolver. Los campos adicionales son: class, protocol, ttl, resolver, flags, dnssec.
De forma predeterminada, ZDNS espera recibir una lista de nombres para consultar en un número pequeño de servidores de nombres. Por ejemplo:
echo "google.com" | zdns A --name-servers=8.8.8.8,8.8.4.4
Sin embargo, hay ocasiones en las que desea consultar el mismo nombre en una gran cantidad de servidores. Esto se puede lograr usando el modo de servidor de nombres. Por ejemplo:
echo "8.8.8.8" | zdns A --name-server-mode --override-name="google.com"
Aquí, cada línea que se pasa a ZDNS recibe una consulta A para google.com. ZDNS también admite mezclar y combinar ambos modos pasando una lista delimitada por comas de name,nameServer. Por ejemplo:
echo "google.com,8.8.8.8" | zdns A enviará una consulta A para google.com a 8.8.8.8 independientemente de los servidores de nombres especificados por el indicador --name-servers=. Las líneas que no especifiquen explícitamente un servidor de nombres usarán los servidores especificados por el sistema operativo o el indicador --name-servers como sucedería normalmente.
Hay una función disponible para realizar una consulta DNS determinada contra todos los servidores de nombres. Por ejemplo, es posible que desee obtener los registros A de todos los servidores de nombres de un determinado dominio. Para hacerlo, puede hacer:
echo "google.com" | zdns A --all-nameservers
ZDNS admite el uso de múltiples módulos de consulta en una sola invocación. Por ejemplo, supongamos que desea realizar una consulta A, AAAA y MXLOOKUP para un conjunto de dominios y desea realizarlas con resolución iterativa. Necesitará usar el módulo MULTIPLE y proporcionar un archivo de configuración con los módulos y las banderas específicas del módulo que desea usar.
Consulte zdns --help y zdns <MODULE_NAME> --help para conocer las opciones globales y específicas del módulo que se pueden usar en el archivo de configuración.
Por ejemplo:
cat 1000k_domains.txt | zdns MULTIPLE --multi-config-file="./multiple.ini"
Donde multiple.ini es un archivo que se ve así:
; Especificar opciones globales aquí
[Application Options]
iterative=true
; Listar módulos y sus respectivas opciones específicas del módulo aquí. Un módulo solo se puede listar una vez
[MXLOOKUP]
ipv4-lookup = true
; Puede usar valores predeterminados y simplemente listar módulos si no necesita especificar opciones
[A]
[AAAA]
Se proporciona un archivo multiple.ini de muestra en src/cli/multiple.ini
De forma predeterminada, ZDNS operará con 1,000 gorutinas ligeras. Si no tiene cuidado, esto abrumará a muchos proveedores de DNS ascendentes. Sugerimos que los usuarios se coordinen con los administradores de red locales antes de realizar cualquier escaneo. Puede controlar el número de conexiones concurrentes con los argumentos de línea de comandos --threads y --go-processes. Se pueden especificar servidores de nombres alternativos con --name-servers. ZDNS rotará entre estos servidores al realizar solicitudes. Hemos ejecutado ZDNS con éxito con decenas de miles de rutinas ligeras.
Si zdns encuentra un tipo de registro que no soporta, generará un registro de salida con el campo type establecido correctamente y una representación de la estructura de datos subyacente en el campo unparsed_rr. No confíe en la presencia o estructura de este campo. Este campo (y su existencia) puede cambiar en cualquier momento a medida que ampliamos el soporte para tipos de registro adicionales. Si se encuentra usando este campo, considere enviar una solicitud de extracción añadiendo soporte de análisis.
Hay un benchmark disponible en benchmark/ que se puede usar para ejecutar ZDNS de manera predecible e imprimir algunas estadísticas sobre la ejecución. Esto puede ser útil para comparar el rendimiento antes y después de un cambio en ZDNS. Consulte más detalles en el README del benchmark.
Si está interesado en contribuir a ZDNS, consulte CONTRIBUTING.
ZDNS Copyright 2020 Regents of the University of Michigan
Licenciado bajo la Licencia Apache, Versión 2.0 (la "Licencia"); no puede usar este archivo excepto en cumplimiento de la Licencia. Puede obtener una copia de la Licencia en http://www.apache.org/licenses/LICENSE-2.0
A menos que lo exija la ley aplicable o se acuerde por escrito, el software distribuido bajo la Licencia se distribuye "TAL CUAL", SIN GARANTÍAS NI CONDICIONES DE NINGÚN TIPO, ya sean expresas o implícitas. Consulte la Licencia para el idioma específico que rige los permisos y limitaciones bajo la Licencia.
Go está contento de usar todos los núcleos de CPU que están disponibles para él, y puede usar una cantidad tremenda de CPU si especifica un número grande de hilos. La CPU se utiliza principalmente para análisis y codificación JSON. Si desea limitar el número de núcleos de CPU, puede hacerlo incluyendo el indicador --go-processes=n o configurando la variable de entorno GOMAXPROCS.
Es difícil recomendar una cantidad precisa de --threads ya que depende de varios factores. El gráfico a continuación muestra cómo un flujo de trabajo de muestra tiene un tiempo de ejecución menor pero tasas más altas de fallo de resolución de nombres a medida que aumenta el número de hilos.