gha-lab-6904b2ccbe

Il resolver RethinkDNS

RethinkDNS esegue serverless-dns in produzione su questi endpoint:

L'elaborazione lato server richiede da 0 millisecondi (ms) a 2ms (mediana), e la latenza end-to-end (varia in base a regioni e reti) è tra 10ms e 30ms (mediana).

Il resolver Rethink DNS su Fly.io è sponsorizzato da FOSS United.

Self-hosting

Cloudflare Workers è la piattaforma più semplice su cui configurare serverless-dns:

Per istruzioni passo-passo, fai riferimento a:

Per configurare le blocklist, visita https://<my-domain>.tld/configure dal tuo browser (dovrebbe caricare qualcosa di simile alla pagina configure di RethinkDNS).

Per aiuto o assistenza, sentiti libero di aprire un issue o inviare una patch.

Sviluppo

Configurazione

Codice:

Node:

Deno:

Fastly:

Wrangler:

Stile del codice

I commit su questo repository applicano la guida allo stile JavaScript di Google (rif: .eslintrc.cjs). Un hook git pre-commit esegue il linter (eslint) e il formatter (prettier) sui file .js. Usa git commit --no-verify per bypassare questo hook.

Le pull request vengono anche controllate per violazioni dello stile del codice e corrette automaticamente dove possibile.

Variabili d'ambiente

Configura env.js se devi modificare le impostazioni predefinite. Per Cloudflare Workers, configura le variabili d'ambiente in wrangler.toml, invece. Per Fastly Compute@Edge, configura le variabili d'ambiente in fastly.toml, invece.

Flusso delle richieste

1. Il flusso richiesta/risposta: client <-> src/server-[node|workers|deno] <-> doh.js <-> plugin.js
2. Il flusso di plugin.js: user-op.js -> cache-resolver.js -> cc.js -> resolver.js

Autenticazione

serverless-dns supporta l'autenticazione con un token bearer alfanumerico sia per DoH che per DoT. Per un token, msg-key (segreto), aggiungi l'output di hex(hmac-sha256(msg-key|domain.tld), msg) alla variabile d'ambiente ACCESS_KEYS in formato csv. Nota: msg è attualmente fisso su sdns-public-auth-info.

1. DoH: posiziona il msg-key alla fine del blockstamp, in questo modo: 1:1:4AIggAABEGAgAA:<msg-key> (qui, 1 è la versione, 1:4AIggAABEGAgAA è il blockstamp, <msg-key> è il segreto di autenticazione, e : è il delimitatore).
2. DoT: posiziona il msg-key alla fine dell'SNI (nome di dominio) contenente il blockstamp: 1-4abcbaaaaeigaiaa-<msg-key> (qui 1 è la versione, 4abcbaaaaeigaiaa è il blockstamp, <msg-key> è il segreto di autenticazione, e - è il delimitatore).

Se l'intenzione è usare l'autenticazione anche con DoT, mantieni il msg-key più corto (da 8 a 24 caratteri), poiché i sottodomini possono essere lunghi al massimo 63 caratteri in totale.

Puoi generare le chiavi di accesso per il tuo fork da max.rethinkdns.com, in questo modo:

Log e Analytics

serverless-dns può essere configurato per caricare i log tramite Cloudflare Logpush.

0. Configura un job Logpush:
   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, setup a filter such that only logs form this worker ends up being pushed; but if you
   # do not need a filter on Worker name (script-name), edit the "filter" field below accordingly.
   SCRIPT_NAME=<name-of-the-worker-as-in-wrangler-toml>
   # for more options, ref: developers.cloudflare.com/logs/get-started/api-configuration
   # Logpush API with cURL: developers.cloudflare.com/logs/tutorials/examples/example-logpush-curl
   # Available Logpull fields: 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. Imposta la proprietà logpush = true in wrangler.toml, che abilita Logpush.
2. (Opzionale) Variabile d'ambiente LOG_LEVEL = "logpush", che alza il livello di log in modo che vengano emessi solo i log di richiesta e di errore.
3. (Opzionale) Imposta la variabile d'ambiente LOGPUSH_SRC = "csv,of,subdomains", che fa sì che log-pusher.js emetta log di richiesta solo se l'hostname dei Workers contiene uno dei sottodomini.

I log pubblicati su R2 possono essere recuperati usando le R2 Workers, l'API R2, o l'API Logpush.

Workers Analytics, se abilitato, viene inviato contro una log-key, lid, che se non specificata è impostata all'hostname della distribuzione serverless con i punti, ., sostituiti da underscore, _. L'autenticazione deve essere configurata quando si interrogano le Analytics tramite l'API che restituisce un json; es: https://max.rethinkdns.com/1:<optional-stamp>:<msg-key>/analytics?t=<time-interval-in-mins>&f=<field-name>. I possibili fields sono ip (ip del client), qname (nome della query DNS), region (regione del resolver), qtype (tipo di query DNS), dom (domini di primo livello), ansip (ip delle risposte DNS) e cc (codici paese degli ip delle risposte).

La cattura dei log e le analytics non sono ancora implementate per Fly e Deno Deploy.

Una nota sui runtime

Deno Deploy (cloud) e Deno (il runtime) non espongono la stessa superficie API (per esempio, Deno Deploy supporta solo listener HTTP/S; mentre Deno supporta TCP/UDP/TLS grezzi oltre a HTTP semplice e HTTP/S).

Tranne su Node, serverless-dns usa upstream DoH definiti dalle variabili d'ambiente CF_DNS_RESOLVER_URL / CF_DNS_RESOLVER_URL_2. Su Node, l'upstream DNS predefinito è 1.1.1.2 (rif) o il resolver DNS ricorsivo su fdaa::3 quando si esegue su Fly.io.

Gli entrypoint per Node e Deno sono rispettivamente src/server-node.js e src/server-deno.ts, ed entrambi ascoltano connessioni TCP-over-TLS e HTTP/S; mentre l'entrypoint per Cloudflare Workers, che ascolta solo su HTTP (cli) o su HTTP/S (prod), è src/server-workers.js; e per Fastly è src/server-fastly.js.

Le configurazioni locali (non-prod) su Node, i file key (privata) e cert (catena pubblica), per impostazione predefinita, vengono letti dai percorsi definiti nelle variabili d'ambiente TLS_KEY_PATH e TLS_CRT_PATH.

Mentre per la configurazione di produzione su Node (su Fly.io), TLS_OFFLOAD deve essere impostato su true oppure key e cert devono essere codificati in base64 nella variabile d'ambiente TLS_CERTKEY (rif), in questo modo:

Per Deno, i file key e cert vengono letti dai percorsi definiti nelle variabili d'ambiente TLS_KEY_PATH e TLS_CRT_PATH (rif).

L'avvio del processo è diverso per ciascuno di questi runtime: per Node, src/core/node/config.js governa l'avvio; mentre per Deno è src/core/deno/config.ts, e per Workers è src/core/workers/config.js. src/system.js pub-sub coordina la fase di avvio tra i vari moduli.

Su Node e Deno, la cache DNS in-process è supportata da @serverless-dns/lfu-cache; Cloudflare Workers è supportato sia dalla Cache Web API che dalle cache lfu in-process. Per disabilitare completamente la cache su tutte e tre le piattaforme, imposta la variabile d'ambiente PROFILE_DNS_RESOLVES=true.

Cloud

Cloudflare Workers e Deno Deploy sono effimeri, nel senso che il "processo" che serve le richieste dei client non è di lunga durata, e infatti due richieste consecutive possono essere servite da due isolates ("processi") diversi. Fastly Compute@Edge è anch'esso effimero ma non usa isolates; invece Fastly crea e distrugge una sandbox wasmtime per ogni richiesta. Il resolver su Fly.io, che esegue Node, è supportato da VM persistenti ed è quindi di durata più lunga, come gli ambienti tradizionali "serverfull".

Per Deno Deploy, il code-base viene raggruppato in un singolo file javascript con deno bundle e poi consegnato a Deno.com.

Le configurazioni di build-time e runtime di Cloudflare Workers sono definite in wrangler.toml. Webpack5 raggruppa i file in un modulo ESM che viene poi caricato su Cloudflare da Wrangler.

Le configurazioni di build-time e runtime di Fastly Compute@Edge sono definite in fastly.toml. Webpack5 raggruppa i file in un modulo ESM che viene poi compilato in WASM da npx js-compute-runtime e successivamente impacchettato e pubblicato su Fastly Compute@Edge con la Fastly CLI.

Per Fly.io, che esegue Node, le direttive runtime sono definite in fly.toml (usato dai tipi di distribuzione dev e live), mentre le direttive di deploy sono in node.Dockerfile. flyctl configura di conseguenza serverless-dns sull'infrastruttura di Fly.io.

Per i deploy che scaricano la terminazione TLS su Fly.io (tipo di distribuzione B1), le direttive runtime sono invece definite in fly.tls.toml, che configura HTTP2 Cleartext e HTTP/1.1 sulla porta 443, e DNS su TCP sulla porta 853.

Rif: github/workflows.

Blocklist

190+ blocklist sono compresse in un Succinct Radix Trie (basato sull'implementazione di Steve Hanov) con modifiche per velocizzare la ricerca di stringhe (lookup) a scapito della "succintness". Le blocklist sono versionate con timestamp unix (definito in src/basicconfig.json scaricato da pre.sh), che viene generato una volta a settimana, ma vorremmo generarlo quotidianamente / ogni ora, se possibile vedi), e ospitate su Cloudflare R2 (variabile d'ambiente: CF_BLOCKLIST_URL).

serverless-dns scarica 3 file di blocklist necessari per configurare il radix-trie durante l'avvio del runtime oppure li scarica lazily, quando serve una richiesta DNS.

serverless-dns compila circa ~13M di voci (a gennaio 2023) da circa 190+ blocklist. Queste sono definite nel repository serverless-dns/blocklists.