gha-lab-6904b2ccbe

O resolvedor RethinkDNS

O RethinkDNS executa serverless-dns em produção nestes endpoints:

O processamento no servidor leva de 0 milissegundos (ms) a 2ms (mediana), e a latência de ponta a ponta (varia entre regiões e redes) é entre 10ms e 30ms (mediana).

O resolvedor Rethink DNS no Fly.io é patrocinado pela FOSS United.

Auto-hospedagem

O Cloudflare Workers é a plataforma mais fácil para configurar serverless-dns:

Para instruções passo a passo, consulte:

Para configurar listas de bloqueio, visite https://<my-domain>.tld/configure no seu navegador (deve carregar algo semelhante à página de configuração do RethinkDNS).

Para ajuda ou assistência, sinta-se à vontade para abrir uma issue ou submeter um patch.

Desenvolvimento

Configuração

Código:

Node:

Deno:

Fastly:

Wrangler:

Estilo de código

Os commits neste repositório aplicam o guia de estilo JavaScript do Google (ref: .eslintrc.cjs). Um hook git pre-commit executa o linter (eslint) e o formatador (prettier) em ficheiros .js. Use git commit --no-verify para contornar este hook.

Os pull requests também são verificados quanto a violações de estilo de código e corrigidos automaticamente quando possível.

Variáveis de ambiente

Configure env.js se precisar de ajustar os padrões. Para Cloudflare Workers, configure as variáveis de ambiente em wrangler.toml, em vez disso. Para Fastly Compute@Edge, configure as variáveis de ambiente em fastly.toml, em vez disso.

Fluxo de pedidos

1. O fluxo de pedido/resposta: cliente <-> src/server-[node|workers|deno] <-> doh.js <-> plugin.js
2. O fluxo de plugin.js: user-op.js -> cache-resolver.js -> cc.js -> resolver.js

Autenticação

O serverless-dns suporta autenticação com um token de portador alfanumérico tanto para DoH como para DoT. Para um token, msg-key (segredo), anexe a saída de hex(hmac-sha256(msg-key|domain.tld), msg) à variável de ambiente ACCESS_KEYS em formato csv. Nota: msg está atualmente fixado em sdns-public-auth-info.

1. DoH: coloque o msg-key no final do blockstamp, assim: 1:1:4AIggAABEGAgAA:<msg-key> (aqui, 1 é a versão, 1:4AIggAABEGAgAA é o blockstamp, <msg-key> é o segredo de autenticação, e : é o delimitador).
2. DoT: coloque o msg-key no final do SNI (nome de domínio) que contém o blockstamp: 1-4abcbaaaaeigaiaa-<msg-key> (aqui 1 é a versão, 4abcbaaaaeigaiaa é o blockstamp, <msg-key> é o segredo de autenticação, e - é o delimitador).

Se a intenção for usar autenticação também com DoT, mantenha o msg-key mais curto (8 a 24 caracteres), pois os subdomínios podem ter apenas 63 caracteres no total.

Pode gerar as chaves de acesso para o seu fork a partir de max.rethinkdns.com, assim:

Registos e Analytics

O serverless-dns pode ser configurado para carregar registos via Cloudflare Logpush.

0. Configure um trabalho 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. Defina a propriedade logpush = true em wrangler.toml, o que ativa o Logpush.
2. (Opcional) Variável de ambiente LOG_LEVEL = "logpush", que aumenta o nível de registo para que apenas os registos de pedidos e erros sejam emitidos.
3. (Opcional) Defina a variável de ambiente LOGPUSH_SRC = "csv,of,subdomains", que faz com que log-pusher.js emita registos de pedidos apenas se o hostname dos Workers contiver um dos subdomínios.

Os registos publicados no R2 podem ser recuperados usando R2 Workers, a API R2, ou a API Logpush.

O Workers Analytics, se ativado, é enviado contra uma chave de registo, lid, que, se não for especificada, é definida como o hostname da implementação serverless com os pontos, ., substituídos por underscores, _. A autenticação deve ser configurada ao consultar o Analytics via API, que retorna um json; ex: https://max.rethinkdns.com/1:<optional-stamp>:<msg-key>/analytics?t=<time-interval-in-mins>&f=<field-name>. Os fields possíveis são ip (ip do cliente), qname (nome da consulta DNS), region (região do resolvedor), qtype (tipo de consulta DNS), dom (domínios de topo), ansip (ips de resposta DNS) e cc (códigos de país dos ips de resposta).

A captura de registos e analytics ainda não está implementada para Fly e Deno Deploy.

Uma nota sobre runtimes

O Deno Deploy (cloud) e o Deno (o runtime) não expõem a mesma superfície de API (por exemplo, o Deno Deploy apenas suporta listeners de servidor HTTP/S; enquanto o Deno suporta TCP/UDP/TLS brutos, além de HTTP simples e HTTP/S).

Exceto no Node, serverless-dns usa upstreams DoH definidos por variáveis de ambiente, CF_DNS_RESOLVER_URL / CF_DNS_RESOLVER_URL_2. No Node, o upstream DNS padrão é 1.1.1.2 (ref) ou o resolvedor DNS recursivo em fdaa::3 quando executa no Fly.io.

Os pontos de entrada para Node e Deno são src/server-node.js, src/server-deno.ts respetivamente, e ambos escutam conexões TCP-over-TLS, HTTP/S; enquanto o ponto de entrada para Cloudflare Workers, que apenas escuta HTTP (cli) ou HTTP/S (prod), é src/server-workers.js; e para Fastly é src/server-fastly.js.

Em configurações locais (não-prod) no Node, os ficheiros key (privada) e cert (cadeia pública), por padrão, são lidos de caminhos definidos em variáveis de ambiente, TLS_KEY_PATH e TLS_CRT_PATH.

Enquanto para configurações de prod no Node (no Fly.io), ou TLS_OFFLOAD deve ser definido como true ou key e cert devem ser codificados em base64 na variável de ambiente TLS_CERTKEY (ref), assim:

Para Deno, os ficheiros key e cert são lidos de caminhos definidos em variáveis de ambiente, TLS_KEY_PATH e TLS_CRT_PATH (ref).

O arranque do processo é diferente para cada um destes runtimes: Para Node, src/core/node/config.js governa o arranque; enquanto para Deno, é src/core/deno/config.ts, e para Workers é src/core/workers/config.js. O pub-sub de src/system.js coordena a fase de arranque entre vários módulos.

No Node e Deno, o cache DNS em processo é suportado por @serverless-dns/lfu-cache; o Cloudflare Workers é suportado tanto pela Cache Web API como por caches lfu em processo. Para desativar completamente o cache nas três plataformas, defina a variável de ambiente PROFILE_DNS_RESOLVES=true.

Cloud

O Cloudflare Workers e o Deno Deploy são efémeros, ou seja, o "processo" que atende pedidos de clientes não é de longa duração, e, de facto, dois pedidos consecutivos podem ser atendidos por dois isolates ("processos") diferentes. O Fastly Compute@Edge também é efémero, mas não usa isolates; em vez disso, o Fastly cria e destrói uma sandbox wasmtime para cada pedido. O resolvedor no Fly.io, que executa Node, é suportado por VMs persistentes e, portanto, tem maior longevidade, como ambientes tradicionais "serverfull".

Para Deno Deploy, o código é empacotado num único ficheiro javascript com deno bundle e depois entregue ao Deno.com.

As configurações de tempo de compilação e de execução do Cloudflare Workers são definidas em wrangler.toml. O Webpack5 agrupa os ficheiros num módulo ESM que é depois carregado para o Cloudflare pelo Wrangler.

As configurações de tempo de compilação e de execução do Fastly Compute@Edge são definidas em fastly.toml. O Webpack5 agrupa os ficheiros num módulo ESM que é depois compilado para WASM por npx js-compute-runtime e subsequentemente empacotado e publicado no Fastly Compute@Edge com a Fastly CLI.

Para Fly.io, que executa Node, as diretivas de execução são definidas em fly.toml (usado pelos tipos de implementação dev e live), enquanto as diretivas de implementação estão em node.Dockerfile. O flyctl configura adequadamente o serverless-dns na infraestrutura do Fly.io.

Para implementações que descarregam a terminação TLS para o Fly.io (tipo de implementação B1), as diretivas de execução são, em vez disso, definidas em fly.tls.toml, que configura HTTP2 Cleartext e HTTP/1.1 na porta 443, e DNS sobre TCP na porta 853.

Ref: github/workflows.

Listas de bloqueio

190+ listas de bloqueio são comprimidas numa Succinct Radix Trie (baseada na impl de Steve Hanov) com modificações para acelerar a pesquisa de strings (lookup) à custa da "succintness". As listas de bloqueio são versionadas com timestamp unix (definido em src/basicconfig.json descarregado por pre.sh), que é gerado uma vez por semana, mas gostaríamos de gerá-las diariamente / de hora em hora, se possível ver), e hospedadas no Cloudflare R2 (variável de ambiente: CF_BLOCKLIST_URL).

O serverless-dns descarrega 3 ficheiros de listas de bloqueio necessários para configurar a radix-trie durante o arranque do runtime ou descarrega-os lazily, ao atender um pedido DNS.

O serverless-dns compila cerca de ~13M entradas (desde jan 2023) de cerca de 190+ listas de bloqueio. Estas são definidas no repositório serverless-dns/blocklists.