引言：边缘计算重新定义 DNS 解析
在传统的 DNS 解析架构中，递归解析器往往部署在固定的数据中心，这种中心化的部署模式在全球互联网用户分布日益分散的今天面临着显著的性能挑战。当用户与 DNS 服务器之间的物理距离较远时，网络延迟会显著增加，这直接影响着网页加载速度和整体用户体验。
serverless-dns 项目以其创新的多平台统一部署架构打破了这一传统模式，通过在 Cloudflare Workers、Deno Deploy、Fastly Compute@Edge 和 Fly.io 等边缘计算平台上部署 DNS 解析器，实现了真正的全球分布式解析服务。根据官方数据，其端到端延迟控制在 10-30 毫秒范围内，而服务器端处理时间仅为 0-2 毫秒，这种卓越的性能表现背后蕴含着深刻的工程设计理念。
多云平台统一部署的架构挑战
运行时的差异性处理
serverless-dns 面临的首要挑战是不同边缘计算平台之间的运行时环境差异。Cloudflare Workers 基于 V8 Isolates，Deno Deploy 使用 Deno 运行时，Fastly Compute@Edge 采用 WebAssembly 沙箱，而 Fly.io 则是基于 Node.js 的微虚拟机。这些平台在 API 暴露、文件访问、网络通信以及并发模型方面都存在显著差异。
项目通过抽象统一的入口层来解决这一问题：每个平台都有对应的服务器入口文件（src/server-workers.js、src/server-deno.ts、src/server-fastly.js、src/server-node.js），这些文件负责处理平台特定的请求路由和初始化逻辑，然后在统一的doh.js和plugin.js中进行核心业务处理。
配置文件与环境变量的平台化适配
不同平台的配置管理方式也各不相同。Cloudflare Workers 使用wrangler.toml进行构建时配置，Fastly Compute@Edge 依赖fastly.toml，而 Fly.io 则使用fly.toml和 Dockerfile 组合。项目设计了平台感知的配置加载机制，通过env.js统一环境变量管理，同时在各个平台的配置文件中保持环境变量的命名一致性，确保配置的可移植性。
对于 TLS 证书管理，项目提供了灵活的解决方案。在本地开发环境中，证书文件通过TLS_KEY_PATH和TLS_CRT_PATH环境变量指定文件路径；在生产环境中，特别是 Fly.io 部署，可以选择将 TLS 终止卸载到平台（设置TLS_OFFLOAD=true）或使用 base64 编码的环境变量TLS_CERTKEY。
边缘计算的性能优化策略
缓存架构的分层设计
serverless-dns 的缓存设计体现了对边缘计算特性的深刻理解。在 Cloudflare Workers 上，项目同时使用 Cache Web API 和进程内的 LFU 缓存，形成了两级缓存架构：外部缓存利用 Cloudflare 的全球网络进行内容分发，进程内缓存提供毫秒级的本地访问性能。
对于 Deno 和 Node 运行时，项目采用了@serverless-dns/lfu-cache作为进程内缓存实现。这种 LFU（Least Frequently Used）缓存策略在 DNS 解析场景中特别有效，因为热门域名的解析请求会占据绝大部分流量，缓存这些请求能够显著减少对上游递归解析器的调用。
地理分布与智能路由
项目的全球分布能力基于各大边缘计算平台的地理覆盖。Cloudflare Workers 提供 280 + 个边缘节点，Deno Deploy 覆盖 30 + 地区，Fastly Compute@Edge 拥有 80 + 个节点，而 Fly.io 部署 30 + 个数据中心。这种广泛的地理分布确保了用户请求能够在最近的边缘节点得到处理，从而最小化网络延迟。
通过CF_DNS_RESOLVER_URL和CF_DNS_RESOLVER_URL_2环境变量，项目支持配置多个上游递归解析器。在默认情况下，Node 运行时使用 1.1.1.2 作为上游解析器，而在 Fly.io 上运行时会使用 fdaa::3 的 IPv6 地址作为递归解析器。
内容过滤与安全机制
大规模黑名单的高效存储
serverless-dns 集成了 190 + 个黑名单列表，包含约 1300 万个条目。为了在边缘环境中高效处理这些数据，项目采用了基于 Succinct Radix Trie 的压缩存储方案。该方案基于 Steve Hanov 的实现，但针对字符串查找进行了优化，在牺牲部分 "简洁性" 的前提下提升了查找性能。
黑名单数据通过pre.sh脚本从serverless-dns/blocklists仓库编译而来，每周生成一次版本化的数据文件，并存储在 Cloudflare R2 中。解析器在启动时会下载三个必需的黑名单文件，或者在处理 DNS 请求时进行懒加载。
认证与访问控制
为了确保服务的安全性和资源的合理使用，serverless-dns 实现了基于 HMAC-SHA256 的认证机制。对于 DNS over HTTPS (DoH)，认证令牌包含在 blockstamp 中，格式为1:1:4AIggAABEGAgAA:<msg-key>；对于 DNS over TLS (DoT)，认证信息则嵌入在 SNI 字段中，格式为1-4abcbaaaaeigaiaa-<msg-key>。
这种设计允许在不同子域名上部署不同级别的认证策略，同时保持了客户端配置的简洁性。认证密钥通过max.rethinkdns.com的端点生成，基于用户提供的 msg-key 和域名计算 HMAC 值。
监控与分析的系统化实现
日志收集的边缘优化
在 Cloudflare Workers 平台上，serverless-dns 集成了 Logpush 机制进行日志收集。系统通过log-pusher.js插件将请求日志推送到 Cloudflare R2 对象存储，同时支持通过LOGPUSH_SRC环境变量进行子域名过滤，仅收集特定域名的请求日志。
这种设计既满足了合规性要求，又控制了存储成本。日志数据可以通过 R2 Workers API、R2 S3 API 或 Logpush API 进行检索和分析。
实时分析与可视化
项目还提供了基于 API 的实时分析功能，支持查询客户端 IP 地址、查询域名、解析器地区、DNS 查询类型、顶级域名以及回答 IP 地址等多个维度的统计信息。分析结果以 JSON 格式返回，便于集成到外部监控系统中。
部署与运维的最佳实践
构建流程的自动化
项目的构建流程针对不同平台进行了优化。Cloudflare Workers 使用 Webpack 5 进行模块打包，通过 Wrangler CLI 进行部署；Fastly Compute@Edge 同样使用 Webpack 打包，但最终编译为 WebAssembly 格式；Fly.io 则采用 Docker 构建流程，支持基于 TLS 卸载和纯 HTTP 两种部署模式。
这种差异化的构建策略确保了每个平台都能获得最优的运行时性能，同时保持了代码库的相对统一。
开发体验的持续改进
项目维护了严格的代码规范，遵循 Google JavaScript Style Guide，通过 ESLint 和 Prettier 在提交时自动检查和格式化代码。开发者可以使用./run脚本快速启动不同运行时的本地开发环境，还集成了 Clinic.js 进行性能分析。
结论与展望
serverless-dns 项目通过创新的多平台统一部署架构，成功将 DNS 解析服务扩展到全球边缘节点，实现了传统解析器难以达到的性能水平。其架构设计充分体现了边缘计算的理念：通过将计算能力分布到用户附近，显著降低了服务延迟，提升了用户体验。
项目在处理运行时差异性、实现高性能缓存、集成大规模内容过滤以及建立完善的监控体系等方面都展现了深厚的工程功底。对于需要在全球范围内提供 DNS 服务的组织来说，serverless-dns 提供了一个值得参考的解决方案，特别是在成本控制和运维简化方面具有明显优势。
未来，随着边缘计算平台的不断发展和 DNS-over-HTTP/3 等新协议的普及，类似 serverless-dns 这样的边缘原生 DNS 服务架构将会在互联网基础设施中发挥更加重要的作用。
资料来源
- GitHub - serverless-dns/serverless-dns: The RethinkDNS resolver that deploys to Cloudflare Workers, Deno Deploy, Fastly, and Fly.io. https://github.com/serverless-dns/serverless-dns
- RethinkDNS Documentation - Open Source DNS hosting guides. https://docs.rethinkdns.com/dns/open-source