zmap/zdnsSchnelle DNS-Nachschlagebibliothek und CLI-Tool
ZDNS ist ein Hochgeschwindigkeits-DNS-Resolver und ein Befehlszeilenwerkzeug zur Durchführung von großflächigen DNS-Messungen. ZDNS ist in Go geschrieben und enthält einen eigenen rekursiven Auflösungscode sowie einen Cache, der für die Suche einer Vielzahl von Namen optimiert ist. Wir verwenden https://github.com/zmap/dns zum Erstellen und Parsen von rohen DNS-Paketen. Weitere Informationen zur Architektur und Leistung von ZDNS finden Sie im folgenden Paper, das auf der ACM Internet Measurement Conference '22 erschienen ist.
[!TIP] Das ZDNS Wiki enthält zusätzliche Informationen zu ZDNS und führt durch Anwendungsfälle und Beispiele.
ZDNS kann installiert werden, indem das Repository ausgecheckt und make install ausgeführt wird.
git clone https://github.com/zmap/zdns.git
cd zdns
make install
ZDNS besteht aus einer rekursiven Resolver-Bibliothek und einem CLI-Wrapper.
Die Bibliothek besteht aus einer ResolverConfig-Struktur, die alle Konfigurationsoptionen für alle durchgeführten Lookups enthält. Die ResolverConfig wird verwendet, um 1+ Resolver-Strukturen zu erstellen, die alle Lookups durchführen. Ein Resolver sollte nur einen einzelnen Lookup gleichzeitig durchführen (er ist nicht threadsicher) und mehrere Resolver-Strukturen sollten für Parallelisierung verwendet werden. Siehe unsere Beispiele zur Verwendung der Bibliothek. Module werden verwendet, um das Verhalten der Lookups zu definieren.
ZDNS bietet verschiedene Arten von Modulen:
Raw DNS-Module liefern die rohe DNS-Antwort vom Server, ähnlich wie dig, jedoch im JSON-Format. Es gibt ein Modul für (fast) jeden DNS-Record-Typ.
Lookup-Module liefern hilfreichere Antworten, wenn mehrere Abfragen erforderlich sind (z. B. Durchführung einer zusätzlichen A-Abfrage für IP-Adressen, wenn ein NS in NSLOOKUP empfangen wird).
Sonstige Module bieten weitere zusätzliche Möglichkeiten zur Abfrage von Servern (z. B. bind.version).
Wir beschreiben die Module im Folgenden:
Die Module 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 und URI liefern die rohe DNS-Antwort im JSON-Format, ähnlich wie dig.
Zum Beispiel liefert der Befehl:
echo "censys.io" | zdns A
zurück:
{
"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"
}
}
}
Rohe DNS-Antworten liefern häufig nicht die Daten, die Sie möchten. Beispielsweise enthält eine MX-Antwort möglicherweise nicht die zugehörigen A-Records im zusätzlichen Abschnitt, was eine zusätzliche Abfrage erforderlich macht. Um diese Lücke zu schließen und eine benutzerfreundlichere Oberfläche bereitzustellen, bieten wir auch mehrere Lookup-Module an: alookup, mxlookup und nslookup.
alookup verhält sich ähnlich wie nslookup und folgt CNAME-Records.
mxlookup führt zusätzlich eine A-Abfrage für die IP-Adressen durch, die einem Exchange-Record entsprechen.
nslookup führt zusätzlich eine A/AAAA-Abfrage für IP-Adressen durch, die einem NS-Record entsprechen.
Zum Beispiel:
echo "censys.io" | zdns mxlookup --ipv4-lookup
gibt zurück:
{
"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 unterstützt auch spezielle "Debug"-DNS-Abfragen. Zu den Modulen gehören: BINDVERSION.
ZDNS unterstützt die Bereitstellung von Eingaben in verschiedenen Formaten, abhängig vom gewünschten Verhalten.
Die grundlegendste Eingabe ist eine Liste von Namen, die durch Zeilenumbrüche getrennt sind. Zum Beispiel:
Über stdin:
echo "google.com\nyahoo.com" | zdns A
cat list_of_domains.txt | zdns A
Aus einer Datei:
zdns A --input-file=list_of_domains.txt
Wenn Sie nicht viele Domains auflösen müssen, wird die Angabe der Domain als CLI-Argument ähnlich wie bei dig aus Gründen der Benutzerfreundlichkeit unterstützt.
Zum Beispiel:
zdns A google.com --name-servers=1.1.1.1
Entspricht dig -t A google.com @1.1.1.1
Normalerweise wählt ZDNS für jede Domain-Abfrage einen zufälligen Nameserver aus --name-servers aus. Wenn Sie stattdessen für jede Domain einen anderen Nameserver angeben möchten, können Sie dies tun, indem Sie Paare von domainName,nameServerIP durch Zeilenumbrüche getrennt angeben. Dies überschreibt alle mit --name-servers angegebenen Nameserver.
Zum Beispiel:
echo "google.com,1.1.1.1\nfacebook.com,8.8.8.8" | zdns A
Sie sehen den resolver wie angegeben für jede Domain in der Ausgabe (zur Kürze redigierte Zusätze/Antworten):
$ 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"}}}
Zonendateien (von ICANN CZDS oder ähnlich) können als Eingabequelle für ZDNS mit dem Flag --zone-file verwendet werden. Dies ermöglicht das Parsen von Zonendateien entweder von stdin (Standard) oder aus einer Datei mit dem Flag --input-file.
Standardmäßig extrahiert ZDNS nur den Namen aus jedem Zonendatei-Eintrag. Wenn Sie auch die Namen auflösen möchten, die im Antwortabschnitt von Record-Typen wie CNAMEs oder NS-Records referenziert werden, können Sie das CLI-Flag --zone-file-include-targets verwenden.
Zum Beispiel mit --zone-file-include-targets und diesem DNS-Zonendatei-Eintrag:
example.com. 3600 IN NS ns1.example.com
würden sowohl example.com als auch ns1.example.com aufgelöst.
ZDNS unterstützt auch die Übergabe von "Triggern" pro Eingabezeile, die Eingabezeilen bestimmten Modulen zuordnen. Damit können Sie festlegen, dass bestimmte Domains mit bestimmten Modulen abgefragt werden.
Das Eingabeformat lautet:
domain_name,name_server,trigger,trigger_2,etc, wobei nameServer leer sein kann, um die Standard-Nameserver zu verwenden, und 1+ Trigger angegeben werden können.
Eine Beispiel-input.csv-Datei:
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
Und die entsprechende multiple.ini:
; Geben Sie hier globale Optionen an
[Application Options]
iterative=true
prefer-ipv6-iteration="true"
; Listen Sie hier Module und ihre jeweiligen modulspezifischen Optionen auf. Ein Modul kann nur einmal aufgeführt werden
[A]
trigger = "a-trigger"
[AAAA]
trigger = "aaaa-trigger"
[CNAME]
trigger = "cname-trigger"
Dies führt folgende Lookups durch:
example.com mit dem A-Modul unter Verwendung der Standard-Nameservergoogle.com mit den A- + CNAME-Modulen unter Verwendung der Standard-Nameserverexample.com mit dem AAAA-Modul unter Verwendung des Cloudflare-Resolver 1.1.1.1yahoo.com mit allen angegebenen Modulen und unter Verwendung der Standard-Nameserverapnews.com mit allen angegebenen Modulen und unter Verwendung des Cloudflare-Resolver 1.1.1.1Ausführen des Befehls:
zdns MULTIPLE --multi-config-file="./multiple.ini" --input-file="input.csv"
ZDNS kann entweder gegen einen rekursiven Resolver (z. B. einen DNS-Server der Organisation) [Standardverhalten] arbeiten oder seine eigene Rekursion intern durchführen. Wenn Sie eine kleine Anzahl von Lookups durchführen (d. h. Millionen) und weniger als 10.000 Go-Routinen verwenden, ist es in der Regel am schnellsten, einen der gängigen rekursiven Resolver wie Cloudflare oder Google zu verwenden. Cloudflare ist fast immer schneller als Google. Dies gilt insbesondere dann, wenn Sie nach bekannten Namen suchen, da diese zwischengespeichert sind und in einem einzigen Roundtrip beantwortet werden können. Wenn Sie zehntausende gleichzeitige Threads verwenden, sollten Sie die Iteration intern durchführen, um eine Überlastung und/oder Ratenbegrenzung Ihres rekursiven Resolvers zu vermeiden.
Um eine lokale Rekursion durchzuführen, führen Sie zdns mit dem Flag --iterative aus. Wenn dieses Flag verwendet wird, wechselt ZDNS im Round-Robin-Verfahren zwischen den veröffentlichten Root-Servern (z. B. 198.41.0.4). Im iterativen Modus können Sie die Größe des lokalen Caches mit --cache-size und das Timeout für einzelne Iterationen mit --iteration-timeout steuern. Das Flag --timeout steuert das Timeout für die gesamte Auflösung einer bestimmten Eingabe (d. h. die Summe aller Iterationsschritte).
Die Leistung von ZDNS beruht auf massiver Parallelisierung unter Verwendung von leichtgewichtigen Go-Routinen. Diese Architektur hat mehrere Besonderheiten:
Jede Go-Routine verwendet ihren eigenen dedizierten Netzwerk-Socket. Daher müssen Sie so viele Sockets öffnen können (sowohl in Bezug auf maximale Dateideskriptoren als auch auf kurzlebige Ports), wie Sie Threads angegeben haben (über --threads). Standardmäßig verwendet ZDNS 1.000 Threads, was weniger ist als das Linux-Standardmaximum von 1024 offenen Dateideskriptoren. Es ist jedoch größer als der Mac OS-Standard von 256. Sie können die maximale Anzahl offener Dateideskriptoren (und damit Sockets) anzeigen, indem Sie ulimit -n ausführen. Wenn Sie mit einer größeren Anzahl von Threads als dieser Zahl arbeiten möchten, müssen Sie die Anzahl der offenen Dateien auf Betriebssystemebene erhöhen. Wenn Sie dies nicht tun, erhalten Sie einen schwerwiegenden Fehler ähnlich wie FATA[0000] unable to create socketlisten udp <client IP address>:0: socket: too many open files. Wenn Sie mehr Threads ausführen möchten, als kurzlebige Ports verfügbar sind, müssen Sie mehrere Client-IP-Adressen verwenden: --local-addr=A,B,C.
Standardmäßig "wiederverwendet" ZDNS UDP-Sockets, indem es für jede leichtgewichtige Routine beim Start einen ungebundenen UDP-Socket erstellt und ihn für alle Abfragen (unabhängig von der Ziel-IP) verwendet. Dies verbessert die Leistung dramatisch, da ZDNS und das Host-Betriebssystem keinen Socket für jedes einzelne Paket einrichten und abbauen müssen (da DNS-Abfragen/-Antworten in der Regel jeweils ein Paket sind). Dies bedeutet jedoch, dass ZDNS beim Start einen Socket pro Thread vorab zuweist. Dies ist möglicherweise nicht optimal, wenn Sie nur eine kleine Anzahl von Namen nachschlagen. Wenn Sie beispielsweise nur 100 Namen nachschlagen müssen, aber die Standardeinstellung von 1.000 Threads verwenden, binden Sie 900 UDP-Sockets, die nie verwendet werden. Anstatt sich um das Recycling von Sockets zu kümmern, empfehlen wir, eine angemessene Anzahl von Threads für Ihren Anwendungsfall anzugeben (da dies auch die Arbeit zum Starten dieser Threads überflüssig macht). Aus diesem Grund können Sie jedoch einen Fehler erhalten, dass eine große Anzahl von Sockets nicht geöffnet werden kann, obwohl Sie nur einen einzigen Namen nachschlagen. Wenn es wichtig ist, für jede Abfrage einen neuen Socket zu erstellen, können Sie diese Wiederverwendung deaktivieren, indem Sie angeben.
Die Leistung, die Sie erzielen, hängt stark von Ihrem Workflow, Ihrer Hardware und der Anzahl der Nameserver ab, auf die die Last verteilt wird. Wenn Sie die Leistung für Ihren Workflow/Ihre Hardware maximieren möchten, empfehlen wir, bei 100 Threads zu beginnen und zu erhöhen, bis Sie eine Zunahme von Fehlern bei der Namensauflösung feststellen. Verwenden Sie dazu --output-file=output.jsonl und grep -v "NOERROR" output.jsonl | wc -l, um die Anzahl der fehlgeschlagenen Namensauflösungen zu zählen. Flags, die bei der Leistungsoptimierung hilfreich sein können, sind:
--timeout Die maximale Zeit, die ZDNS für einen einzelnen Namen aufwendet.--iteration-timeout Die maximale Zeit, die ZDNS für einen einzelnen Iterationsschritt aufwendet (z.B. Auflösung von google.com auf der .com-Ebene).--network-timeout Die maximale Zeit, die ZDNS auf eine Antwort eines Nameservers wartet.--retries=N Wenn eine Verbindung zu einem bestimmten Nameserver in --iterative fehlschlägt, wiederholt ZDNS mit einem anderen, noch nicht abgefragten Nameserver auf dieser Ebene. Wiederholungen erfolgen pro Name. Wenn also --retries=1 ist, wiederholt ZDNS einen Namen einmalig gegen einen neuen Nameserver während seines vollständigen Iterationsprozesses. Wenn alle Nameserver abgefragt wurden, wird ein zufälliger Nameserver ausgewählt.--name-servers Die Liste der für Lookups zu verwendenden Nameserver, hauptsächlich nützlich mit --iterative=false.DNS enthält viele zusätzliche Daten, die nicht immer nützlich sind. Es gibt vier Detaillierungsstufen: short, normal (Standardeinstellung), long und trace:
short: Short ist die prägnanteste Ergebnisausgabe. Sie enthält nur Informationen über die Antworten.normal: Normal liefert alles, was in short enthalten ist, sowie Daten über den antwortenden Server.long: Long gibt alles aus, was der Server in das DNS-Paket aufgenommen hat, einschließlich Flags.trace: Trace gibt bei jedem Schritt des Rekursionsprozesses alles aus.Benutzer können auch bestimmte zusätzliche Felder mit dem Flag --include-fields und einer Liste von Feldern einfügen, z. B. --include-fields=flags,resolver. Zusätzliche Felder sind: class, protocol, ttl, resolver, flags, dnssec.
Standardmäßig erwartet ZDNS eine Liste von Namen, die auf einer kleinen Anzahl von Nameservern nachgeschlagen werden sollen. Zum Beispiel:
echo "google.com" | zdns A --name-servers=8.8.8.8,8.8.4.4
Es gibt jedoch Zeiten, in denen Sie denselben Namen auf einer großen Anzahl von Servern nachschlagen möchten. Dies kann mit dem Nameserver-Modus erreicht werden. Zum Beispiel:
echo "8.8.8.8" | zdns A --name-server-mode --override-name="google.com"
Hier wird jede an ZDNS weitergeleitete Zeile mit einer A-Abfrage für google.com gesendet. ZDNS unterstützt auch die Mischung beider Modi, indem eine durch Kommas getrennte Liste von name,nameServer weitergeleitet wird. Zum Beispiel:
echo "google.com,8.8.8.8" | zdns A sendet eine A-Abfrage für google.com an 8.8.8.8, unabhängig davon, welche Nameserver durch das Flag --name-servers= angegeben wurden. Zeilen, die keinen expliziten Nameserver angeben, verwenden die vom Betriebssystem oder durch das Flag --name-servers angegebenen Server wie gewohnt.
Es gibt eine Funktion, um eine bestimmte DNS-Abfrage gegen alle Nameserver durchzuführen. Sie möchten zum Beispiel die A-Records von allen Nameservern einer bestimmten Domain erhalten. Dazu können Sie:
echo "google.com" | zdns A --all-nameservers
ZDNS unterstützt die Verwendung mehrerer Lookup-Module in einem einzigen Aufruf. Angenommen, Sie möchten A-, AAAA- und MXLOOKUP-Abfragen für eine Reihe von Domains durchführen und diese mit iterativer Auflösung durchführen. Sie müssen das Modul MULTIPLE verwenden und eine Konfigurationsdatei mit den Modulen und modulspezifischen Flags bereitstellen, die Sie verwenden möchten.
Bitte beachten Sie zdns --help und zdns <MODULE_NAME> --help für globale und modulspezifische Optionen, die in der Konfigurationsdatei verwendet werden können.
Zum Beispiel:
cat 1000k_domains.txt | zdns MULTIPLE --multi-config-file="./multiple.ini"
Wobei multiple.ini eine Datei ist, die wie folgt aussieht:
; Geben Sie hier globale Optionen an
[Application Options]
iterative=true
; Listen Sie hier Module und ihre jeweiligen modulspezifischen Optionen auf. Ein Modul kann nur einmal aufgeführt werden
[MXLOOKUP]
ipv4-lookup = true
; Sie können Standardwerte verwenden und Module einfach auflisten, wenn Sie keine Optionen angeben müssen
[A]
[AAAA]
Eine Beispiel-multiple.ini-Datei ist in src/cli/multiple.ini bereitgestellt.
Standardmäßig arbeitet ZDNS mit 1.000 leichtgewichtigen Go-Routinen. Wenn Sie nicht vorsichtig sind, wird dies viele vorgelagerte DNS-Anbieter überlasten. Wir empfehlen Benutzern, sich mit den lokalen Netzwerkadministratoren abzustimmen, bevor sie Scans durchführen. Sie können die Anzahl der gleichzeitigen Verbindungen mit den Befehlszeilenargumenten --threads und --go-processes steuern. Alternative Nameserver können mit --name-servers angegeben werden. ZDNS rotiert bei Anfragen durch diese Server. Wir haben ZDNS erfolgreich mit Zehntausenden von leichtgewichtigen Routinen betrieben.
Wenn zdns auf einen Record-Typ stößt, den es nicht unterstützt, erzeugt es einen Ausgabedatensatz mit dem korrekt gesetzten Feld type und einer Darstellung der zugrunde liegenden Datenstruktur im Feld unparsed_rr. Verlassen Sie sich nicht auf das Vorhandensein oder die Struktur dieses Feldes. Dieses Feld (und seine Existenz) kann sich jederzeit ändern, wenn wir die Unterstützung für zusätzliche Record-Typen erweitern. Wenn Sie feststellen, dass Sie dieses Feld verwenden, sollten Sie in Betracht ziehen, einen Pull-Request mit Parser-Unterstützung einzureichen.
Es gibt einen Benchmark in benchmark/, der verwendet werden kann, um ZDNS auf vorhersehbare Weise auszuführen und einige Statistiken über den Lauf auszugeben. Dies kann nützlich sein, um die Leistung vor und nach einer Änderung an ZDNS zu vergleichen. Weitere Details finden Sie im Benchmark-README.
Wenn Sie daran interessiert sind, zu ZDNS beizutragen, lesen Sie CONTRIBUTING.
ZDNS Copyright 2020 Regents of the University of Michigan
Lizenziert unter der Apache License, Version 2.0 (die "Lizenz"); Sie dürfen diese Datei nur in Übereinstimmung mit der Lizenz verwenden. Eine Kopie der Lizenz erhalten Sie unter http://www.apache.org/licenses/LICENSE-2.0
Sofern nicht durch geltendes Recht vorgeschrieben oder schriftlich vereinbart, wird die unter der Lizenz verteilte Software OHNE JEGLICHE GEWÄHRLEISTUNG, weder ausdrücklich noch stillschweigend, bereitgestellt. Weitere Einzelheiten zu Berechtigungen und Einschränkungen finden Sie in der Lizenz.
--recycle-sockets=falseGo verwendet gerne alle verfügbaren CPU-Kerne und kann bei einer großen Anzahl von Threads eine enorme Menge an CPU verbrauchen. Die CPU wird hauptsächlich zum Parsen und für die JSON-Codierung verwendet. Wenn Sie die Anzahl der CPU-Kerne begrenzen möchten, können Sie dies mit dem Flag --go-processes=n oder der Umgebungsvariablen GOMAXPROCS tun.
Eine genaue Empfehlung für die Anzahl der --threads ist schwierig, da sie von mehreren Faktoren abhängt. Die folgende Grafik zeigt, wie ein Beispiel-Workflow mit zunehmender Thread-Anzahl eine kürzere Laufzeit, aber höhere Fehlerraten bei der Namensauflösung aufweist.