gha-lab-6904b2ccbe

Der RethinkDNS-Resolver

RethinkDNS betreibt serverless-dns in Produktion an diesen Endpunkten:

Die serverseitige Verarbeitung dauert zwischen 0 Millisekunden (ms) und 2 ms (Median), und die Ende-zu-Ende-Latenz (variiert je nach Region und Netzwerk) liegt zwischen 10 ms und 30 ms (Median).

Der Rethink DNS-Resolver auf Fly.io wird von FOSS United gesponsert.

Selbst hosten

Cloudflare Workers ist die einfachste Plattform, um serverless-dns einzurichten:

Für Schritt-für-Schritt-Anleitungen siehe:

Um Blocklisten einzurichten, besuche https://<meine-domain>.tld/configure in deinem Browser (es sollte etwas Ähnliches wie die Konfigurationsseite von RethinkDNS geladen werden).

Für Hilfe oder Unterstützung kannst du gerne ein Issue eröffnen oder einen Patch einreichen.

Entwicklung

Einrichtung

Node:

Node:

Deno:

Fastly:

Wrangler:

Codestil

Commits in diesem Repository erzwingen den Google-JavaScript-Styleguide (ref: .eslintrc.cjs). Ein Git-pre-commit-Hook führt Linter (eslint) und Formatierer (prettier) auf .js-Dateien aus. Verwende git commit --no-verify, um diesen Hook zu umgehen.

Pull-Requests werden ebenfalls auf Verstöße gegen den Codestil überprüft und wo möglich automatisch korrigiert.

Umgebungsvariablen

Konfiguriere env.js, wenn du die Standardwerte anpassen musst. Für Cloudflare Workers richte stattdessen Umgebungsvariablen in wrangler.toml ein. Für Fastly Compute@Edge richte stattdessen Umgebungsvariablen in fastly.toml ein.

Anfrageablauf

1. Der Anfrage-/Antwortfluss: Client <-> src/server-[node|workers|deno] <-> doh.js <-> plugin.js
2. Der plugin.js-Fluss: user-op.js -> cache-resolver.js -> cc.js -> resolver.js

Authentifizierung

serverless-dns unterstützt die Authentifizierung mit einem alphanumerischen Bearer-Token sowohl für DoH als auch für DoT. Für ein Token, msg-key (Geheimnis), hänge die Ausgabe von hex(hmac-sha256(msg-key|domain.tld), msg) an die Umgebungsvariable ACCESS_KEYS im CSV-Format an. Hinweis: msg ist derzeit auf sdns-public-auth-info festgelegt.

1. DoH: Platziere den msg-key am Ende des Blockstempels, wie folgt: 1:1:4AIggAABEGAgAA:<msg-key> (hier ist 1 die Version, 1:4AIggAABEGAgAA der Blockstempel, <msg-key> das Auth-Geheimnis und : das Trennzeichen).
2. DoT: Platziere den msg-key am Ende des SNI (Domainnamens), der den Blockstempel enthält: 1-4abcbaaaaeigaiaa-<msg-key> (hier ist 1 die Version, 4abcbaaaaeigaiaa der Blockstempel, <msg-key> das Auth-Geheimnis und - das Trennzeichen).

Wenn die Absicht besteht, Auth auch mit DoT zu verwenden, halte msg-key kürzer (8 bis 24 Zeichen), da Subdomains insgesamt nur 63 Zeichen lang sein dürfen.

Du kannst die Zugriffsschlüssel für deinen Fork von max.rethinkdns.com generieren, wie folgt:

Protokolle und Analysen

serverless-dns kann so eingerichtet werden, dass Protokolle über Cloudflare Logpush hochgeladen werden.

0. Richte einen Logpush-Job ein:
   root@kitploit:~

   CF_ACCOUNT_ID=<hex-cloudflare-account-id>
   CF_API_KEY=<api-key-with-logs-edit-permission-at-account-level>
   R2_BUCKET=<r2-bucket-name>
   R2_ACCESS_KEY=<r2-access-key-for-the-bucket>
   R2_SECRET_KEY=<r2-secret-key-with-read-write-permissions>
   # optional, richte einen Filter ein, sodass nur Protokolle dieses Workers übertragen werden; wenn du
   # jedoch keinen Filter auf den Workernamen (script-name) benötigst, bearbeite das Feld "filter" unten entsprechend.
   SCRIPT_NAME=<name-of-the-worker-as-in-wrangler-toml>
   # für weitere Optionen, ref: developers.cloudflare.com/logs/get-started/api-configuration
   # Logpush-API mit cURL: developers.cloudflare.com/logs/tutorials/examples/example-logpush-curl
   # Verfügbare Logpull-Felder: developers.cloudflare.com/logs/reference/log-fields/account/workers_trace_events
   curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/${CF_ACCOUNT_ID}/logpush/jobs" \
       -H "Authorization: Bearer ${CF_API_KEY}" \
       -H 'Content-Type: application/json' \
       -d '{
           "name": "dns-logpush",
           "logpull_options": "fields=EventTimestampMs,Outcome,Logs,ScriptName&timestamps=rfc3339",
           "destination_conf": "r2://'"$R2_BUCKET"'/{DATE}?access-key-id='"${R2_ACCESS_KEY}"'&secret-access-key='"${R2_SECRET_KEY}"'&account-id='"{$CF_ACCOUNT_ID}"',
           "dataset": "workers_trace_events",
           "filter": "{\"where\":{\"and\":[{\"key\":\"ScriptName\",\"operator\":\"contains\",\"value\":\"'"${SCRIPT_NAME}"'\"},{\"key\":\"Outcome\",\"operator\":\"eq\",\"value\":\"ok\"}]}}",
           "enabled": true,
           "frequency": "low"
       }'
   

1. Setze die Eigenschaft logpush = true in wrangler.toml, was Logpush aktiviert.
2. (Optional) Umgebungsvariable LOG_LEVEL = "logpush", die die Protokollebene so anhebt, dass nur Anfrage- und Fehlerprotokolle ausgegeben werden.
3. (Optional) Setze die Umgebungsvariable LOGPUSH_SRC = "csv,of,subdomains", die log-pusher.js veranlasst, Anfrage-Protokolle nur dann auszugeben, wenn der Workers-hostname eine der Subdomains enthält.

An R2 veröffentlichte Protokolle können entweder über R2 Workers, die R2-API oder die Logpush-API abgerufen werden.

Workers Analytics wird, falls aktiviert, gegen einen Protokollschlüssel, lid, übertragen, der, wenn nicht angegeben, auf den Hostnamen der serverlosen Bereitstellung gesetzt wird, wobei Punkte, ., durch Unterstriche, _, ersetzt werden. Auth muss eingerichtet sein, wenn du über die API nach Analytics fragst, die ein JSON zurückgibt; z. B.: https://max.rethinkdns.com/1:<optional-stamp>:<msg-key>/analytics?t=<time-interval-in-mins>&f=<field-name>. Mögliche fields sind ip (Client-IP), qname (DNS-Abfragename), region (Resolver-Region), qtype (DNS-Abfragetyp), dom (Top-Level-Domains), ansip (DNS-Antwort-IPs) und cc (Antwort-IP-Ländercodes).

Protokollerfassung und Analysen sind für Fly und Deno Deploy noch nicht implementiert.

Eine Anmerkung zu Laufzeiten

Deno Deploy (Cloud) und Deno (die Laufzeit) legen nicht dieselbe API-Oberfläche offen (z. B. unterstützt Deno Deploy nur HTTP/S-Server-Listener; während Deno zusätzlich zu einfachem HTTP und HTTP/S auch rohes TCP/UDP/TLS unterstützt).

Außer auf Node verwendet serverless-dns DoH-Upstreams, die durch Umgebungsvariablen definiert sind, CF_DNS_RESOLVER_URL / CF_DNS_RESOLVER_URL_2. Auf Node ist der Standard-DNS-Upstream 1.1.1.2 (ref) oder der rekursive DNS-Resolver unter fdaa::3, wenn auf Fly.io ausgeführt.

Die Einstiegspunkte für Node und Deno sind src/server-node.js bzw. src/server-deno.ts, und beide lauschen auf TCP-over-TLS-, HTTP/S-Verbindungen; während der Einstiegspunkt für Cloudflare Workers, der nur über HTTP (cli) oder über HTTP/S (prod) lauscht, src/server-workers.js ist; und für Fastly ist es src/server-fastly.js.

Lokale (Nicht-Prod-)Einrichtungen auf Node lesen key- (privat) und cert- (öffentliche Kette) Dateien standardmäßig aus Pfaden, die in Umgebungsvariablen definiert sind, TLS_KEY_PATH und TLS_CRT_PATH.

Für die Produktionseinrichtung auf Node (auf Fly.io) muss entweder TLS_OFFLOAD auf true gesetzt werden oder key und cert müssen base64 in der Umgebungsvariablen TLS_CERTKEY kodiert sein (ref), wie folgt:

Für Deno werden key- und cert-Dateien aus Pfaden gelesen, die in Umgebungsvariablen definiert sind, TLS_KEY_PATH und TLS_CRT_PATH (ref).

Der Prozess-Start ist für jede dieser Laufzeiten unterschiedlich: Für Node steuert src/core/node/config.js den Start; während es für Deno src/core/deno/config.ts ist, und für Workers ist es src/core/workers/config.js. src/system.js Pub-Sub koordiniert die Start-Phase zwischen verschiedenen Modulen.

Auf Node und Deno wird der prozessinterne DNS-Cache durch @serverless-dns/lfu-cache unterstützt; Cloudflare Workers wird sowohl durch die Cache-Web-API als auch durch prozessinterne LFU-Caches unterstützt. Um das Caching auf allen drei Plattformen vollständig zu deaktivieren, setze die Umgebungsvariable PROFILE_DNS_RESOLVES=true.

Cloud

Cloudflare Workers und Deno Deploy sind ephemer, d. h. der "Prozess", der Client-Anfragen bedient, ist nicht langlebig, und tatsächlich können zwei aufeinanderfolgende Anfragen von zwei verschiedenen Isolates ("Prozessen") bedient werden. Fastly Compute@Edge ist ebenfalls ephemer, verwendet jedoch keine Isolates; stattdessen erstellt und zerstört Fastly für jede Anfrage eine wasmtime-Sandbox. Der Resolver auf Fly.io, der Node ausführt, wird durch persistente VMs unterstützt und ist daher langlebiger, wie traditionelle "serverfull"-Umgebungen.

Für Deno Deploy wird die Codebasis mit deno bundle in einer einzigen JavaScript-Datei gebündelt und dann an Deno.com übergeben.

Die Build- und Laufzeitkonfigurationen von Cloudflare Workers sind in wrangler.toml definiert. Webpack5 bündelt die Dateien in einem ESM-Modul, das dann von Wrangler zu Cloudflare hochgeladen wird.

Die Build- und Laufzeitkonfigurationen von Fastly Compute@Edge sind in fastly.toml definiert. Webpack5 bündelt die Dateien in einem ESM-Modul, das dann von npx js-compute-runtime zu WASM kompiliert und anschließend mit der Fastly-CLI verpackt und auf Fastly Compute@Edge veröffentlicht wird.

Für Fly.io, das Node ausführt, sind die Laufzeitanweisungen in fly.toml definiert (verwendet für dev- und live-Bereitstellungstypen), während die Bereitstellungsanweisungen in node.Dockerfile sind. flyctl richtet serverless-dns entsprechend auf der Infrastruktur von Fly.io ein.

Für Bereitstellungen, die die TLS-Terminierung an Fly.io auslagern (B1-Bereitstellungstyp), sind die Laufzeitanweisungen stattdessen in fly.tls.toml definiert, das HTTP2-Cleartext und HTTP/1.1 auf Port 443 sowie DNS over TCP auf Port 853 einrichtet.

Ref: github/workflows.

Blocklisten

190+ Blocklisten werden in einem Succinct Radix Trie komprimiert (basiert auf Steve Hanovs Implementierung) mit Modifikationen, um die Zeichenfolgensuche (lookup) auf Kosten der "Succinctness" zu beschleunigen. Die Blocklisten werden mit Unix-Zeitstempel versioniert (definiert in src/basicconfig.json, heruntergeladen von pre.sh), der einmal pro Woche generiert wird, aber wir möchten sie täglich / stündlich generieren, wenn möglich siehe), und auf Cloudflare R2 gehostet (Umgebungsvariable: CF_BLOCKLIST_URL).

serverless-dns lädt 3 Blocklistendateien herunter, die zum Einrichten des Radix-Trie während des Laufzeit-Starts erforderlich sind, oder lädt sie lazy herunter, wenn eine DNS-Anfrage bedient wird.

serverless-dns kompiliert rund ~13M Einträge (Stand Januar 2023) aus rund 190+ Blocklisten. Diese sind im Repository serverless-dns/blocklists definiert.