Repository navigation
fix(dns): integrate managed proxy DNS repair - #441
Conversation
审阅者指南此 PR 修复了托管默认 DNS 出站流量的问题:使模板和运行时始终对未分类查询使用代理 DoH;代理不可用时采用失败关闭策略;并保留独立的直连引导解析器,用于查找代理节点。此 PR 还增强了诊断功能,以检查实际生效的 DNS 引用和流量转发路径;更新了可复现的源码/模板固定版本及配方契约;并记录了针对性的 CI 验证和明确的设备测试限制。 托管默认 DNS 代理出站流量时序图sequenceDiagram
participant Client as 客户端
participant Runtime as 运行时
participant DNSCore as DNS 核心
participant Proxy as 代理
participant DoH as doh_cloudflare
participant Bootstrap as bootstrap_local_dns
Client->>Runtime: magicnet_dns_apply_singbox()
Runtime->>DNSCore: 使用 doh_cloudflare 进行评估/响应
DNSCore->>Proxy: 建立 DoH 的 CONNECT 连接
Proxy->>DoH: 解析未分类查询
DoH-->>DNSCore: DNS 响应
DNSCore-->>Client: 返回响应
alt 代理不可用
DNSCore-->>Client: 查询失败
DNSCore--x Bootstrap: 不进行直连回退
end
DNSCore->>Bootstrap: 解析代理节点域名
Bootstrap-->>DNSCore: 节点地址
实际生效的 DNS 诊断流程图flowchart TD
A[未分类 DNS 查询] --> B[解析实际生效的 dns.final]
B --> C[检查 evaluate/respond 解析器]
C --> D{解析器的 detour 是否为 proxy?}
D -->|是| E[受保护的默认 DNS]
D -->|否| F[诊断失败]
C --> G{是否存在显式 Direct、LAN 或自定义 DNS 图?}
G -->|是| H[保留并验证显式行为]
G -->|否| D
文件级变更
提示与命令与 Sourcery 互动
自定义使用体验访问你的控制面板以进行以下操作:
获取帮助Original review guide in EnglishReviewer's GuideThis PR fixes managed-default DNS egress by making the template and runtime consistently use proxied DoH for uncategorized queries, failing closed when proxy access is unavailable, and retaining a separate direct bootstrap resolver for proxy-node lookup. It also strengthens diagnostics to inspect the effective DNS reference and detour, updates reproducible source/template pins and recipe contracts, and documents targeted CI validation plus explicit device-testing limits. Sequence diagram for managed default DNS proxy egresssequenceDiagram
participant Client
participant Runtime
participant DNSCore
participant Proxy
participant DoH as doh_cloudflare
participant Bootstrap as bootstrap_local_dns
Client->>Runtime: magicnet_dns_apply_singbox()
Runtime->>DNSCore: evaluate/respond using doh_cloudflare
DNSCore->>Proxy: CONNECT for DoH
Proxy->>DoH: Resolve uncategorized query
DoH-->>DNSCore: DNS response
DNSCore-->>Client: Return response
alt proxy unavailable
DNSCore-->>Client: Query failure
DNSCore--x Bootstrap: No direct fallback
end
DNSCore->>Bootstrap: Resolve proxy node domain
Bootstrap-->>DNSCore: Node address
Flow diagram for effective DNS diagnosticsflowchart TD
A[Uncategorized DNS query] --> B[Resolve effective dns.final]
B --> C[Inspect evaluate/respond resolver]
C --> D{Resolver detour is proxy?}
D -->|Yes| E[Protected default DNS]
D -->|No| F[Diagnostic failure]
C --> G{Explicit Direct, LAN, or custom DNS graph?}
G -->|Yes| H[Preserve and validate explicit behavior]
G -->|No| D
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Sorry @LIghtJUNction, you've used your own review budget of 250,000 diff characters for the last 7 days. You can request another review in 1 minute by commenting |
Codex Review Summary: ❌ FailedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
The account paying for this security review has reached its Codex usage limits. The payer can check the Codex usage dashboard. For personal accounts, using credits requires enabling “Use credits for security reviews” in Code review settings. If you do not manage the paying account, contact this repository's admins. |
Problem
The managed DNS default could send unclassified lookups to the direct bootstrap resolver while destination traffic used a proxy. This integration keeps the rebuild requirements, fixed source and delivery evidence aligned with the repair.
Changes
magicnet-android@38c6eea6a42eb5f2cc3697c81225f35fd3c82d5candMagicSingBox@ba5793b41fd06704102116fe2536eef5988f2905.Validation
1fdc0caa0c2d412562bc44058b8527210ebad6df75dbc0fcc17d1eba44bab234. All 360 ZIP entries and 10 components / 168 component files pass audit; development/test content is excluded.Android execution evidence is an x86_64 standalone TUN fixture. ARM64 execution, physical devices and user proxy nodes are not claimed. The fixture's product Google probe did not obtain HTTPS 204, although lifecycle and diagnostic controls pass. No formal release or user-device installation was created.
Integration
faa7d956324a20889cb921ff35c9f13b66dc0c1a; its tree matches the tested source.