Astra DNS：把OpenWrt上的优选IP和广告过滤合进一条更简单的DNS链路

项目地址：
astra-dns
luci-app-astra-dns

在 OpenWrt 上折腾 DNS，很多人最后都会走到一个相似的场景：我想让路由器负责全家的 DNS，同时希望它能做广告过滤，还希望访问 Cloudflare 站点时可以自动返回一个更快、更稳定的优选 IP。

单独看，这些需求都不罕见。

广告过滤可以交给 AdGuard Home。DNS 转发、分流、重写可以交给 MosDNS。Cloudflare 优选 IP 可以通过 CloudflareSpeedTest 之类的工具定期测速，再把结果写进 DNS 规则里。代理相关的域名处理，还可能再接入 Mihomo 等组件。

这些工具都很好，也都各自解决了真实问题。但当它们被串在一起时，整个 DNS 链路就会变得有些重。

一个典型的 motivating example

假设我们在 OpenWrt 上已经用了 MosDNS。MosDNS 很适合做 DNS 转发、分流和规则化处理，也可以把某些域名的解析结果改写到指定 IP。于是，如果我们想做 Cloudflare 优选 IP，一个自然的方案是：

1. 用 CloudflareSpeedTest 定期测出当前网络下表现最好的 Cloudflare IP。
2. 把这些 IP 写入 MosDNS 的 rewrite 规则。
3. 当域名解析结果落在 Cloudflare 地址段时，让 MosDNS 返回优选 IP。

这条链路本身是合理的。

但问题来了：MosDNS 并不是广告过滤器。它可以做规则匹配和 DNS 编排，却不直接提供 AdGuard Home 那种完整的广告过滤体验。如果我们还想拦截广告域名，就往往需要再引入一个 DNS 服务，比如 AdGuard Home。

于是原本的需求变成了这样：

客户端
  -> OpenWrt DNS 入口（dnsmasq）
  -> AdGuard Home 负责广告过滤
  -> MosDNS 负责分流、转发和 Cloudflare IP 重写
  -> 上游 DNS

这当然能工作，很多成熟配置也正是这么搭起来的。但它带来的代价也很明显：

• 查询链路变长，每个 DNS 请求都可能跨过多个进程。
• 每个组件都有自己的配置文件、缓存、日志和排错方式。
• 出现问题时，很难第一时间判断到底是广告规则、rewrite 规则、上游 DNS，还是服务转发顺序出了问题。
• OpenWrt 设备资源有限，长期运行多个 DNS 服务并不总是优雅。
• 对普通用户来说，理解整条链路的心智成本很高。

Astra DNS 正是为了解决这个具体场景而设计的：当你只是想在路由器上同时获得广告过滤、DNS 转发和 Cloudflare 优选 IP 重写时，能不能不要把多个 DNS 服务串起来？

Astra DNS 的思路

Astra DNS 是一个基于 Hickory DNS 的 Rust DNS 服务。它的目标是把 OpenWrt 用户最常见的一段工作流合并成一个更直接的 DNS pipeline：

• DNS 转发
• 广告过滤
• 本地域名覆盖
• Cloudflare-oriented rewrite
• 路由器友好的配置和缓存策略

也就是说，一个 DNS 查询进入 Astra DNS 后，可以在同一个服务里完成规则判断、阻断、重写和上游转发，而不是在多个 DNS 服务之间来回传递。

当前 Astra DNS 的处理顺序大致是：

1. 精确的 hosts-style override
2. rewrite override
3. important allow 规则
4. important block 规则
5. 普通 allow 规则
6. 普通 block 规则
7. 上游 DNS 转发

这个顺序很重要。它让解析结果更可解释：一个域名为什么被放行、为什么被拦截、为什么被改写到某个 IP，都能从同一套配置和同一条执行链路里找到答案。

它相比多组件方案的优势

1. 链路更短

传统方案里，广告过滤和 Cloudflare 优选 IP 往往由不同服务完成。Astra DNS 则把这两件事放进同一个 DNS 服务里处理。

这意味着更少的进程、更少的转发层级，也更少的故障点。对于 OpenWrt 这种长期运行在小型设备上的场景，这一点很实用。

2. 配置更聚焦

Astra DNS 支持一个类似 AdGuard Home 的简化上游 DNS 配置：

dns:
  upstream_dns:
    - 127.0.0.1:7874
    - 8.8.8.8

同时，它也支持一个实用子集的广告过滤配置，例如远程过滤列表、本地 user_rules、阻断模式和 rewrite 规则。

它没有试图一次性兼容 AdGuard Home 的全部能力，而是优先覆盖路由器 DNS 场景里最常用、最关键的部分。这种取舍让项目更轻，也更容易理解。

3. Cloudflare 优选 IP 更直接

很多用户折腾 MosDNS rewrite，本质上就是想实现一件事：当上游返回 Cloudflare 地址时，把结果替换成自己测速得到的优选 IP。

Astra DNS 原生支持基于返回 IP/CIDR 的 answer rewrite，也支持 CNAME target rewrite。比如当解析结果命中 Cloudflare 地址段，Astra DNS 可以直接返回指定的优选 IP。

这样一来，CloudflareSpeedTest 产出的结果可以更自然地进入 Astra DNS 的配置，而不需要再围绕多个 DNS 服务设计复杂的转发关系。

LuCI 插件：让 Astra DNS 更像一个 OpenWrt 组件

命令行工具对开发者很友好，但 OpenWrt 用户往往还是希望能在 LuCI 里完成常见操作。

luci-app-astra-dns 就是 Astra DNS 的 LuCI 管理插件。它的设计同样比较克制，没有把界面做成复杂的规则管理系统，而是围绕早期最关键的管理动作展开：

• 启用或关闭 Astra DNS 服务
• 可选将局域网 53 端口重定向到 Astra DNS
• 从 release URL 安装或更新 core binary
• 配置 Astra DNS core 的路径和工作目录
• 编辑 YAML 配置
• 查看运行状态和日志

这种 YAML-centric 的方式有一个好处：它没有隐藏 Astra DNS 的核心配置模型。高级用户仍然可以直接掌控完整配置，而普通用户也可以通过 LuCI 完成启动、更新、保存和排错。

总结

Astra DNS 的价值在于把一个常见但繁琐的路由器 DNS 方案收敛了。

过去，为了同时获得广告过滤和 Cloudflare 优选 IP，我们可能需要把 AdGuard Home、MosDNS、测速脚本和其他网络组件串成一条链。这个方案灵活，但也复杂。

Astra DNS 选择从另一个角度切入：把最常用的过滤、重写和转发逻辑放进一个 Rust DNS 服务里，再通过 LuCI 插件提供 OpenWrt 友好的管理入口。

它的亮点不是功能堆得最多，而是把问题定义得足够清楚：少一些服务串联，少一些配置绕路，让 OpenWrt 上的 DNS 链路更直接、更可解释，也更容易长期维护。

项目地址：
astra-dns
luci-app-astra-dns