zmap/zdnsLibreria di ricerca DNS veloce e strumento CLI
ZDNS è un risolutore DNS ad alta velocità e un'utilità a riga di comando per effettuare misurazioni DNS su larga scala. ZDNS è scritto in Go e contiene il proprio codice di risoluzione ricorsiva e una cache ottimizzata per eseguire ricerche su un insieme eterogeneo di nomi. Utilizziamo https://github.com/zmap/dns per costruire e analizzare pacchetti DNS grezzi. Per maggiori informazioni sull'architettura e le prestazioni di ZDNS, consulta il seguente articolo presentato alla conferenza ACM Internet Measurement Conference '22.
[!TIP] Il Wiki di ZDNS contiene ulteriori informazioni su ZDNS e illustra casi d'uso ed esempi.
ZDNS può essere installato clonando il repository ed eseguendo make install.
git clone https://github.com/zmap/zdns.git
cd zdns
make install
ZDNS è costituito da una libreria di risolutore ricorsivo e da un wrapper CLI.
La libreria contiene una struct ResolverConfig che conterrà tutte le opzioni di configurazione per tutte le ricerche effettuate. Il ResolverConfig viene utilizzato per creare 1+ struct Resolver che eseguiranno tutte le ricerche. Un Resolver dovrebbe eseguire una sola ricerca alla volta (non è thread-safe) e più struct Resolver dovrebbero essere utilizzate per il parallelismo. Consulta i nostri esempi per come utilizzare la libreria. Moduli vengono usati per definire il comportamento delle ricerche.
ZDNS fornisce diversi tipi di moduli:
Moduli DNS grezzi forniscono la risposta DNS grezza dal server, simile a dig, ma in JSON. C'è un modulo per (quasi) ogni tipo di record DNS
Moduli di ricerca forniscono risposte più utili quando sono necessarie più query (ad es., completando una ulteriore ricerca A per indirizzi IP se viene ricevuto un NS in NSLOOKUP)
Moduli vari forniscono altri mezzi aggiuntivi per interrogare i server (ad es., bind.version)
Di seguito descriviamo i moduli:
I moduli 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 e URI forniscono la risposta DNS grezza in formato JSON, simile a dig.
Ad esempio, il comando:
echo "censys.io" | zdns A
restituisce:
{
"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"
}
}
}
Le risposte DNS grezze spesso non forniscono i dati che si desiderano. Ad esempio,
una risposta MX potrebbe non includere i record A associati nella sezione
aggiuntiva, richiedendo una ricerca aggiuntiva. Per colmare questa lacuna e fornire
un'interfaccia più amichevole, forniamo anche diversi moduli di ricerca: alookup,
mxlookup e nslookup.
alookup si comporta in modo simile a nslookup e seguirà i record CNAME.
mxlookup eseguirà inoltre una ricerca A per gli indirizzi IP che corrispondono a un record di scambio.
nslookup eseguirà inoltre una ricerca A/AAAA per gli indirizzi IP che corrispondono a un record NS
Ad esempio,
echo "censys.io" | zdns mxlookup --ipv4-lookup
restituisce:
{
"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 supporta anche query DNS speciali di "debug". I moduli includono: BINDVERSION.
ZDNS supporta la fornitura di input in vari formati a seconda del comportamento desiderato.
L'input più semplice è un elenco di nomi separati da nuove righe. Ad esempio:
Da stdin:
echo "google.com\nyahoo.com" | zdns A
cat list_of_domains.txt | zdns A
Da file
zdns A --input-file=list_of_domains.txt
Se non è necessario risolvere molti domini, per facilità d'uso è supportato fornire il dominio come argomento CLI, simile a dig.
Ad esempio:
zdns A google.com --name-servers=1.1.1.1
Equivalente a dig -t A google.com @1.1.1.1
Normalmente, ZDNS sceglierà un nameserver casuale per ogni ricerca di dominio da --name-servers. Se invece si desidera specificare
un nameserver diverso per ogni dominio, è possibile farlo fornendo coppie nomeDominio,IPnameserver separate da nuove righe.
Ciò sovrascriverà qualsiasi nameserver fornito con --name-servers.
Ad esempio:
echo "google.com,1.1.1.1\nfacebook.com,8.8.8.8" | zdns A
Si può vedere che il resolver è quello specificato per ogni dominio nell'output (additionals/answers omessi per brevità):
$ 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"}}}
I file di zona (da ICANN CZDS o simili) possono essere utilizzati come sorgente di input per ZDNS con il flag --zone-file. Ciò consente di analizzare i file di zona sia da stdin (predefinito) che da un file con il flag --input-file.
Per impostazione predefinita, ZDNS estrarrà solo il nome da ogni record del file di zona. Se si desidera anche risolvere i nomi referenziati nella sezione delle risposte di tipi di record come CNAME o NS, è possibile utilizzare il flag CLI --zone-file-include-targets.
Ad esempio, con --zone-file-include-targets e questa voce del file di zona:
example.com. 3600 IN NS ns1.example.com
verranno risolti sia example.com che ns1.example.com.
ZDNS supporta anche il passaggio di "trigger" per ogni riga di input che mappano le righe di input a moduli specifici. Con questi, è possibile specificare che determinati domini vengano cercati con moduli specifici.
Il formato di input è:
nome_dominio,name_server,trigger,trigger_2,etc, dove nameServer può essere vuoto per utilizzare i nameserver predefiniti e possono essere specificati 1+ trigger.
Un esempio di file input.csv:
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
E il corrispondente multiple.ini:
; Specificare le opzioni globali qui
[Application Options]
iterative=true
prefer-ipv6-iteration="true"
; Elencare qui i moduli e le rispettive opzioni specifiche del modulo. Un modulo può essere elencato una sola volta
[A]
trigger = "a-trigger"
[AAAA]
trigger = "aaaa-trigger"
[CNAME]
trigger = "cname-trigger"
Ciò cercherà:
example.com con il modulo A utilizzando i nameserver predefinitigoogle.com con i moduli A + CNAME utilizzando i nameserver predefinitiexample.com con il modulo AAAA utilizzando il risolutore 1.1.1.1 di Cloudflareyahoo.com con tutti i moduli specificati e utilizzando i nameserver predefinitiapnews.com con tutti i moduli specificati e utilizzando il risolutore 1.1.1.1 di CloudflareEseguendo il comando:
zdns MULTIPLE --multi-config-file="./multiple.ini" --input-file="input.csv"
ZDNS può funzionare sia contro un risolutore ricorsivo (ad es., un server DNS organizzativo) [comportamento predefinito] oppure può eseguire la propria ricorsione internamente. Se si esegue un numero ridotto di ricerche (ad es., milioni) utilizzando meno di 10.000 goroutine, in genere è più veloce utilizzare uno dei comuni risolutor ricorsivi come Cloudflare o Google. Cloudflare è quasi sempre più veloce di Google. Ciò è particolarmente vero se si cercano nomi popolari perché sono nella cache e possono essere risposti in un unico round trip. Quando si utilizzano decine di migliaia di thread concorrenti, si consiglia di eseguire l'iterazione internamente per evitare di sovraccaricare e/o subire limitazioni di velocità dal proprio risolutore ricorsivo.
Per eseguire la ricorsione locale, eseguire zdns con il flag --iterative. Quando questo
flag viene utilizzato, ZDNS eseguirà il round-robin tra i server radice pubblicati (ad es.,
198.41.0.4). In modalità iterativa, è possibile controllare la dimensione della cache locale
specificando --cache-size e il timeout per le singole iterazioni impostando
--iteration-timeout. Il flag --timeout controlla il timeout dell'intera
risoluzione per un dato input (cioè la somma di tutti i passaggi iterativi).
Le prestazioni di ZDNS derivano dalla massiccia parallelizzazione utilizzando goroutine leggere di Go. Questa architettura presenta diversi avvertimenti:
Ogni goroutine utilizza il proprio socket di rete dedicato. Pertanto, è necessario essere in grado di aprire tanti socket (sia in termini di numero massimo di descrittori di file che di porte effimere) quanti sono i thread specificati (tramite --threads). Per impostazione predefinita, ZDNS utilizza 1.000 thread, che è inferiore al numero massimo predefinito di 1024 FD aperti di Linux. Tuttavia, è maggiore del valore predefinito di 256 di Mac OS. È possibile visualizzare il numero massimo di FD aperti (e quindi di socket) consentito eseguendo ulimit -n. Se si desidera eseguire con un numero di thread maggiore di questo numero, è necessario aumentare il numero di file aperti a livello di sistema operativo. Se non si riesce a farlo, si incontrerà un errore fatale simile a FATA[0000] unable to create socketlisten udp <indirizzo IP client>:0: socket: too many open files. Se si desidera eseguire più thread rispetto alle porte effimere disponibili, sarà necessario utilizzare più indirizzi IP client: --local-addr=A,B,C.
Per impostazione predefinita, ZDNS "riutilizza" i socket UDP creando un socket UDP non vincolato per ogni goroutine leggera all'avvio e utilizzandolo per tutte le query (indipendentemente dall'IP di destinazione). Ciò migliora notevolmente le prestazioni perché ZDNS e il sistema operativo host non devono impostare e smontare un socket per inviare ogni singolo pacchetto (poiché le query/risposte DNS tendono ad essere un pacchetto ciascuna). Tuttavia, ciò significa che ZDNS preallocherà un socket per ogni thread all'avvio. Ciò potrebbe non essere ottimale se si cercano solo un piccolo numero di nomi. Ad esempio, se è necessario cercare solo 100 nomi, ma si utilizzano i 1.000 thread predefiniti, si assoceranno ma non si useranno mai 900 socket UDP. Invece di preoccuparsi del riciclo dei socket, consigliamo di specificare un numero ragionevole di thread per il proprio caso d'uso (poiché ciò evita anche il lavoro di avviare quei thread in primo luogo). Questo è il motivo per cui, tuttavia, è possibile ottenere un errore sull'impossibilità di aprire un gran numero di socket anche se si sta cercando un solo nome. Se è importante creare un nuovo socket per ogni query, è possibile disabilitare questo riutilizzo specificando .
Gran parte delle prestazioni che si vedranno dipendono dal flusso di lavoro, dall'hardware e da quanti nameserver è distribuito il carico. Se si desidera massimizzare le prestazioni per il proprio flusso di lavoro/hardware, consigliamo di iniziare con 100 thread e aumentare fino a quando non si inizia a vedere un aumento dei fallimenti nella risoluzione dei nomi. Per aiutare in questo, è possibile utilizzare --output-file=output.jsonl e grep -v "NOERROR" output.jsonl | wc -l per contare il numero di nomi che non sono stati risolti. I flag che possono essere utili per ottimizzare le prestazioni sono:
--timeout Il tempo massimo che ZDNS dedicherà a un singolo nome--iteration-timeout Il tempo massimo che ZDNS dedicherà a un singolo passo di iterazione (ad es.: risoluzione di google.com al livello .com)--network-timeout Il tempo massimo che ZDNS attenderà una risposta da un nameserver--retries=N Se una connessione a un nameserver specifico fallisce in --iterative, ZDNS riproverà con un altro nameserver non ancora interrogato a quel livello. I tentativi sono per nome, quindi se --retries=1, ZDNS ritenterà un nome contro un nuovo nameserver una volta durante l'intero processo di iterazione. Se tutti i nameserver sono stati interrogati, verrà scelto un nameserver casuale.--name-servers L'elenco dei nameserver da utilizzare per le ricerche, utile principalmente con --iterative=falseIl DNS include molti dati estranei che non sono sempre utili. Esistono quattro
livelli di dettaglio del risultato: short, normal (predefinito), long e trace:
short: Short è l'output del risultato più sintetico. Contiene solo le informazioni sulle rispostenormal: Normal fornisce tutto ciò che è incluso in short oltre ai dati sul server che ha rispostolong: Long restituisce tutto ciò che il server ha incluso nel pacchetto DNS, inclusi i flag.trace: Trace restituisce tutto da ogni passo del processo di ricorsioneGli utenti possono anche includere campi aggiuntivi specifici utilizzando il flag --include-fields e specificando un elenco di campi, ad es., --include-fields=flags,resolver.
I campi aggiuntivi sono: class, protocol, ttl, resolver, flags, dnssec.
Per impostazione predefinita, ZDNS si aspetta di ricevere un elenco di nomi da cercare su un piccolo numero di nameserver. Ad esempio:
echo "google.com" | zdns A --name-servers=8.8.8.8,8.8.4.4
Tuttavia, ci sono volte in cui si desidera invece cercare lo stesso nome su un gran numero di server. Ciò può essere ottenuto utilizzando la modalità nameserver. Ad esempio:
echo "8.8.8.8" | zdns A --name-server-mode --override-name="google.com"
Qui, ogni riga inviata tramite pipe a ZDNS viene inviata una query A per google.com. ZDNS supporta anche la combinazione di entrambe le modalità inviando tramite pipe un elenco delimitato da virgole di name,nameServer. Ad esempio:
echo "google.com,8.8.8.8" | zdns A invierà una query A per google.com a 8.8.8.8 indipendentemente dai nameserver specificati dal flag --name-servers=. Le righe che non specificano esplicitamente un nameserver utilizzeranno i server specificati dal sistema operativo o dal flag --name-servers come di consueto.
È disponibile una funzione per eseguire una determinata query DNS su tutti i nameserver. Ad esempio, potresti voler ottenere i record A da tutti i nameserver di un certo dominio. Per fare ciò, puoi eseguire:
echo "google.com" | zdns A --all-nameservers
ZDNS supporta l'utilizzo di più moduli di ricerca in una singola invocazione. Ad esempio, supponiamo di voler eseguire una ricerca A, AAAA e MXLOOKUP per un insieme di domini e di volerle eseguire con risoluzione iterativa. Dovrai utilizzare il modulo MULTIPLE e fornire un file di configurazione con i moduli e i flag specifici del modulo che desideri utilizzare.
Consulta zdns --help e zdns <NOME_MODULO> --help per le opzioni globali e specifiche del modulo che possono essere utilizzate nel file di configurazione.
Ad esempio:
cat 1000k_domains.txt | zdns MULTIPLE --multi-config-file="./multiple.ini"
dove multiple.ini è un file simile a:
; Specificare le opzioni globali qui
[Application Options]
iterative=true
; Elencare qui i moduli e le rispettive opzioni specifiche del modulo. Un modulo può essere elencato una sola volta
[MXLOOKUP]
ipv4-lookup = true
; Puoi usare i valori predefiniti e elencare solo i moduli se non è necessario specificare opzioni
[A]
[AAAA]
Un file multiple.ini di esempio è fornito in src/cli/multiple.ini
Per impostazione predefinita, ZDNS funzionerà con 1.000 goroutine leggere. Se non si sta attenti, ciò sopraffà molti provider DNS a monte. Suggeriamo che gli utenti si coordinino con gli amministratori di rete locali prima di eseguire qualsiasi scansione. È possibile controllare il numero di connessioni concorrenti con gli argomenti da riga di comando --threads e --go-processes. È possibile specificare nameserver alternativi con --name-servers. ZDNS ruoterà attraverso questi server quando effettua richieste. Abbiamo eseguito con successo ZDNS con decine di migliaia di goroutine.
Se zdns incontra un tipo di record che non supporta, genererà un record di output con il campo type impostato correttamente e una rappresentazione della struttura dati sottostante nel campo unparsed_rr. Non fare affidamento sulla presenza o sulla struttura di questo campo. Questo campo (e la sua esistenza) potrebbe cambiare in qualsiasi momento man mano che espandiamo il supporto per ulteriori tipi di record. Se ti trovi a utilizzare questo campo, considera di inviare una richiesta pull per aggiungere il supporto del parser.
È disponibile un benchmark in benchmark/ che può essere utilizzato per eseguire ZDNS in modo prevedibile e stampare alcune statistiche sull'esecuzione. Ciò può essere utile per confrontare le prestazioni prima e dopo una modifica a ZDNS. Vedi ulteriori dettagli nel LEGGIMI del benchmark.
Se sei interessato a contribuire a ZDNS, consulta CONTRIBUTING.
ZDNS Copyright 2020 Regents of the University of Michigan
Concesso in licenza secondo l'Apache License, Versione 2.0 (la "Licenza"); non è possibile utilizzare questo file se non in conformità con la Licenza. È possibile ottenere una copia della Licenza all'indirizzo http://www.apache.org/licenses/LICENSE-2.0
Salvo diversamente previsto dalla legge applicabile o concordato per iscritto, il software distribuito secondo la Licenza è distribuito "COSÌ COM'È", SENZA GARANZIE O CONDIZIONI DI ALCUN TIPO, espresse o implicite. Consultare la Licenza per il linguaggio specifico che regola le autorizzazioni e le limitazioni.
--recycle-sockets=falseGo utilizza volentieri tutti i core CPU a sua disposizione e può utilizzare una quantità enorme di CPU se si specifica un numero elevato di thread. La CPU viene utilizzata principalmente per l'analisi e la codifica JSON. Se si desidera limitare il numero di core CPU, è possibile includere il flag --go-processes=n o impostare la variabile d'ambiente GOMAXPROCS.
È difficile raccomandare una quantità precisa di --threads poiché dipende da diversi fattori. Il grafico seguente mostra come un flusso di lavoro di esempio ha un runtime inferiore ma tassi più elevati di fallimento nella risoluzione dei nomi all'aumentare del numero di thread.