[3alpha]

Context

Follow-up to #81. Update dnscrypt-proxy from 2.1.5 to 2.1.20 and refresh the publishing workflow dependencies, carrying Dappnode's forwarding extension onto the current upstream implementation.

Approach

• Align the upstream version in the package manifest and Compose build arguments at 2.1.20.
• Replace four copied upstream source files with a focused patch for the optional forwarding fallback and forward_fallback_ttl. This allows upstream changes to configuration loading, DNS messages, forwarding, and caching to remain intact.
• Add forwarding regression tests and run them together with the upstream suite during the Docker build. Run tests as an unprivileged user because upstream tests exercise file permissions.
• Shallow-clone the selected upstream tag and remove the redundant module-file copy.
• Update Node.js to 26.12.1, checkout to 7.0.1, and setup-node to 7.1.0 in both publishing workflows. Build CI pulls fresh base images and bypasses layer caching.

Behavior changes to review: upstream now defaults to Weighted Power of Two resolver selection and enables PQDNSCrypt with compatible resolvers. The rebased extension uses upstream error handling for forwarding rules without a fallback; IP fallbacks now return address records matching the query family. The configured .eth CNAME fallback remains supported with a default TTL of 600 seconds.

Test instructions

1. Run docker compose build --pull --no-cache. The build applies the patch and runs the upstream and Dappnode forwarding tests.
2. Start the image with valid _DAPPNODE_GLOBAL_DOMAIN and _DAPPNODE_GLOBAL_INTERNAL_IP values on a network with Dappnode's internal DNS aliases.
3. Verify external DNS resolution, internal .dappnode forwarding, unknown .eth fallback to my.dappnode, and domain/PWA cloaking. Check resolver selection and query latency under a representative workload before rollout.
4. Confirm the self-hosted publishing runner supports the updated Actions and Node.js runtime before invoking the manual release workflow.

Validation: upstream and forwarding tests passed for arm64 and amd64; the image built and its production configuration validated; live external/internal DNS, ENS fallback, and domain/PWA cloaking checks passed with both executables. The amd64 checks ran under emulation. Local image validation used memory-backed compiler scratch space because Docker's disk was full. Publishing workflows were not executed locally.