DNS resolver should filter unspecified addresses (0.0.0.0/::) and retry other nameservers

Description / 问题描述 Symptom / 现象 Connections to outbound proxies intermittently fail with the error: failed to connect outbound: cannot connect to unspecified address 0.0.0.0:xxxx. Once a node's address is resolved to 0.0.0.0, it stays in that state until the application is restarted. After restarting, the node often returns to a normal IP address and becomes functional again. Root Cause Analysis / 根因分析 1. Upstream Blocking: Some upstream DNS servers (especially ad-blocking or filtered DNS) return 0.0.0.0 or :: for certain domains. 2. Acceptance of Invalid IPs: The current EnhancedResolver treats 0.0.0.0 as a valid IP address. 3. Race Condition in batch_exchange: In concurrent queries, if a "bad" DNS server returns 0.0.0.0 faster than other servers return a valid IP, the resolver adopts the 0.0.0.0 result. 4. Cache Poisoning: The 0.0.0.0 result is stored in the LRU cache. Subsequent connection attempts directly use this cached invalid address, leading to persistent failures. Expected Behavior / 预期行为 1. DNS resolution should automatically filter out 0.0.0.0 and :: from the results. 2. If a DNS server returns only unspecified addresses for an A/AAAA query, the resolver should treat it as an error/invalid response and continue waiting for results from other nameservers in the batch_exchange pool. 3. Unspecified addresses should never be cached as valid resolution results. --- Suggested Fix / 建议的修复方案 1. In EnhancedResolver::ip_list_of_message: Add a filter to remove unspecified addresses from the IP list. 1 .filter(|ip| !ip.is_unspecified()) 2. In EnhancedResolver::batch_exchange: Identify responses that contain IP records but result in an empty list after filtering (meaning they only contained 0.0.0.0). Treat these as errors to trigger the select_ok fallback to other clients. 3. In SystemResolver: Apply similar filtering to resolve, resolve_v4, and resolve_v6 to ensure consistency. --- Steps to Reproduce / 重现步骤 1. Configure multiple DNS nameservers, where one is an ad-blocking DNS that returns 0.0.0.0 for a specific proxy domain. 2. Trigger a resolution for that domain. 3. Observe that if the ad-blocking DNS responds first, the proxy connection fails with the 0.0.0.0 error and persists due to caching.